Esiste un valore reale nell'unità di test di un controller in ASP.NET MVC?

Spero che questa domanda dia alcune risposte interessanti perché è quella che mi ha infastidito per un po '.

Esiste un valore reale nell'unità di test di un controller in ASP.NET MVC?

Quello che intendo con ciò è, il più delle volte (e non sono un genio), i miei metodi di controller sono, anche nella loro forma più complessa, qualcosa del genere:

public ActionResult Create(MyModel model)
{
    // start error list
    var errors = new List<string>();

    // check model state based on data annotations
    if(ModelState.IsValid)
    {
        // call a service method
        if(this._myService.CreateNew(model, Request.UserHostAddress, ref errors))
        {
            // all is well, data is saved, 
            // so tell the user they are brilliant
            return View("_Success");
        }
    }

    // add errors to model state
    errors.ForEach(e => ModelState.AddModelError("", e));

    // return view
    return View(model);
}

Gran parte del lavoro pesante viene svolto dalla pipeline MVC o dalla mia biblioteca di servizi.

Quindi forse le domande da porre potrebbero essere:

• quale sarebbe il valore dell'unità test questo metodo?
• non si spezzerebbe Request.UserHostAddresse ModelStatecon una NullReferenceException? Dovrei provare a deridere questi?
• se rifrattassi questo metodo in un "aiutante" riutilizzabile (che probabilmente dovrei, considerando quante volte lo faccio!), testerei che valga la pena anche quando tutto ciò che sto davvero testando è principalmente la "pipeline" che, presumibilmente, è stato testato entro un centimetro dalla sua vita da Microsoft?

Penso che il mio punto sia davvero , fare quanto segue sembra assolutamente inutile e sbagliato

[TestMethod]
public void Test_Home_Index()
{
    var controller = new HomeController();
    var expected = "Index";
    var actual = ((ViewResult)controller.Index()).ViewName;
    Assert.AreEqual(expected, actual);
}

Ovviamente sono ottuso con questo esempio esageratamente inutile, ma qualcuno ha qualche saggezza da aggiungere qui?

Non vedo l'ora ... Grazie.

Anche per qualcosa di così semplice, un unit test avrà molteplici scopi

1. Fiducia, ciò che è stato scritto è conforme alla produzione prevista. Può sembrare banale verificare che restituisca la vista corretta, ma il risultato è una prova oggettiva che il requisito è stato soddisfatto
2. Test di regressione. Se il metodo di creazione deve essere modificato, è ancora presente un test unitario per l'output previsto. Sì, l'output potrebbe cambiare lungo e ciò si traduce in un test fragile ma è comunque un controllo rispetto al controllo delle modifiche non gestito

Per quella particolare azione testerei per quanto segue

1. Cosa succede se _myService è null?
2. Cosa succede se _myService.Create genera un'eccezione, genera specifici da gestire?
3. Un _myService.Create riuscito restituisce la vista _Success?
4. Gli errori vengono propagati fino a ModelState?

Hai sottolineato il controllo di Request e Model per NullReferenceException e penso che ModelState.IsValid si occuperà della gestione di NullReference per Model.

Deridere la richiesta consente di evitare una richiesta nulla che è generalmente impossibile in produzione, penso, ma può accadere in un test unitario. In un test di integrazione ti consentirebbe di fornire valori UserHostAddress diversi (una richiesta è ancora l'input dell'utente per quanto riguarda il controllo e dovrebbe essere testato di conseguenza)

Anche i miei controller sono molto piccoli. La maggior parte della "logica" nei controller viene gestita utilizzando gli attributi di filtro (integrati e scritti a mano). Quindi il mio controller di solito ha solo una manciata di lavori:

• Crea modelli da stringhe di query HTTP, valori di modulo, ecc.
• Eseguire una convalida di base
• Chiama nei miei dati o livello aziendale
• Genera a ActionResult

La maggior parte dell'associazione del modello viene eseguita automaticamente da ASP.NET MVC. DataAnnotations gestisce anche la maggior parte della convalida per me.

Anche con così poco da testare, in genere li scrivo ancora. Fondamentalmente, provo che i miei repository vengono chiamati e che ActionResultviene restituito il tipo corretto . Ho un metodo pratico per ViewResultassicurarmi che venga restituito il percorso di visualizzazione corretto e che il modello di visualizzazione sia come mi aspetto. Ne ho un altro per verificare che sia impostato il controller / azione corretti RedirectToActionResult. Ho altri test per JsonResult, ecc. Ecc.

Un risultato sfortunato della sottoclasse della Controllerclasse è che fornisce molti metodi di praticità che usano HttpContextinternamente. Ciò rende difficile testare l'unità di controllo. Per questo motivo, in genere inserisco HttpContextchiamate dipendenti da un'interfaccia e invio tale interfaccia al costruttore del controller (utilizzo l'estensione web Ninject per creare i miei controller per me). Questa interfaccia di solito è dove applico le proprietà dell'helper per accedere alla sessione, alle impostazioni di configurazione, agli IPrinciple e agli helper URL.

Questo richiede molta diligenza, ma penso che ne valga la pena.

Ovviamente alcuni controller sono molto più complessi di quello ma basati esclusivamente sul tuo esempio:

Cosa succede se myService genera un'eccezione?

Come nota a margine.

Inoltre, metterei in dubbio la saggezza di passare un elenco per riferimento (non è necessario poiché c # passa comunque per riferimento ma anche se non lo fosse) - passare un errore Azione azione (Azione) che il servizio può quindi utilizzare per pompare i messaggi di errore a che potrebbe quindi essere gestito come desiderato (forse si desidera aggiungerlo all'elenco, forse si desidera aggiungere un errore del modello, forse si desidera registrarlo).

Nel tuo esempio:

invece di errori ref, do (string s) => ModelState.AddModelError ("", s) per esempio.