C'è sempre un tempo ragionevole per far testare i dispositivi di prova nella costruzione del controller MVC3?

6

Recentemente ho iniziato con una nuova azienda e sto cercando di capire la meccanica dietro qualcosa, quindi renderò anonimo il codice e presenterò solo un esempio:

[Test(Description = "Retreives the New view for XXXX.")]
public void New()
{
  "~/XXXX/New".ShouldMapTo<XXXXController>(x => x.New());
  "~/XXXX/New".WithMethod(HttpVerbs.Post).ShouldMapTo<XXXXController>(x => x.New(null));
}

e ancora:

[Test(Description = "Test the model injection into the New view.")]
public void New()
{
  var @new = WXYZController.New();
  @new.AssertViewRendered();

  Assert.IsInstanceOf<WXYZSettingsModel>(@new.ViewData.Model, "Expected the data model to be of type WXYZSettingsModel, but the model was another type.");
  var model = @new.ViewData.Model as WXYZSettingsModel;
  if (model == null)
    Assert.Fail("Failed to cast data model to type WXYZSettingsModel.");

    Assert.IsNotNull(model.YYYY, "Expected an instantiated service message, but a null message was returned.");
    Assert.AreEqual(model.YYYY.Status, WXYZ.Success, "Expected a success status code, but another code was returned.");
    Assert.IsNotNull(model.Categories, "");
    Assert.AreEqual(model.ZZZZ.Status, ABCD.Success, "Expected a success status code, but another code was returned.");
}

Mi sembra che questo violi lo scopo dei test unitari, poiché non dovresti mai testare unitamente il framework, ma piuttosto il tuo codice, giusto? Qualcuno si è appena portato via?

O mi manca qualche componente fondamentale di questo codice che è ovvio per qualcuno che ha più familiarità con i test delle unità.

Si noti che ci sono interi file (uno di ciascuno dei precedenti per controller) che non testano mai una singola riga di codice interno, ma sono riempiti con questi test. Anche fino al punto di questo è abbastanza boilerplate ora che l'ho reso anonimo.

Se invece stessimo testando così (pseudocodice ora)

[Test(Description = "thingy tester, duh")]
public void ThingTest(){
  var mock = new MyDataMock();
  var finalMock = new MyFinalMock();
  var controller = new thingController();

  var test = controller.Thing(mock);
  assert.AreNotEqual(test,mock,"It didn't change it");
  assert.AreEqual(test,finalMock,"It worked!");
}

Mi aspetterei che sia quello che dovrebbero essere i test unitari che dovrei vedere, no?

    
posta jcolebrand 20.12.2012 - 18:35
fonte

1 risposta

2

Ci sono casi in cui potresti voler controllare l'idoneità del framework con cui stai lavorando, specialmente in un ambiente regolamentato.

Ad esempio, nello sviluppo di software medico, se si segue la norma IEC 62304, l'uso di Software Of Unknown Providence (SOUP) è un rischio (utilizzando framework di terze parti come ASP.NET MVC Framework o anche .NET Framework è considerato rischioso secondo lo standard). A seconda della Classe del software (A, B o C), è possibile che determinati obblighi ti siano addebitati per valutare i rischi che SOUP apporta al tuo sistema software. Un modo per farlo è eseguire un'unità black-box e test di integrazione delle funzioni che si intende utilizzare nel sistema software, per verificare che funzionino correttamente per i propri scopi. Se segui IEC 62304, sei tecnicamente al corrente di qualsiasi compilatore che usi, per non parlare di componenti o framework di terze parti che potresti decidere di utilizzare.

In definitiva, se il tuo software e il processo sono controllati dalla FDA o da una terza parte, devi essere in grado di mostrare a questi revisori che hai preso misure ragionevoli per convalidare i componenti SOUP, così potresti avere test come questi. / p>     

risposta data 20.12.2012 - 21:33
fonte

Leggi altre domande sui tag