Struttura di test ASP.NET MVC e convenzioni di denominazione

Question

Struttura di test ASP.NET MVC e convenzioni di denominazione

#1 da (1 voti)

1

Ho deciso di fare il grande passo e aggiungere il primo set di test di integrazione e unità ai progetti su cui lavoro (sì, abbiamo dozzine di applicazioni interne senza test automatici di qualsiasi tipo ...).

Mi piacciono molto le cosiddette convenzioni comportamentali per nominare: Given-When-Then, anche se le risorse online sono piuttosto vaghe quando applicate alla struttura del progetto, quindi non sono sicuro di come applicarlo in modo gestibile .

Ad esempio, al momento è come questo:

- Test project

--- IntegrationTests (dir)
------ GivenAHomeController (dir)
--------- WhenAcknowledgingAnUrgentResult.cs
--------- WhenViewingAnUrgentResult.cs
--------- WhenViewingUrgentResults.cs

--- UnitTests (dir)
------ GivenAResultToAcknowledge (dir)
--------- WhenAcknowledgementTypeIsNone.cs

Con un test unitario di esempio:

[TestClass]
public class WhenAcknowledgementTypeIsNone
{
    [TestMethod]
    public void ThenReturnWithModelStateError()
    {
        ...
    }
}

In questo modo sembra che l'abbia semanticamente bloccato ad avere una classe separata per ogni caso di test contenente solo un singolo metodo di test. La classe di test dovrebbe essere più generica con ciascun metodo di test che include più "quando"?

unit-testing integration-tests conventions .net

posta Lee 27.04.2017 - 13:02

fonte

1 risposta

Leggi altre domande sui tag unit-testing integration-tests conventions .net

Sono autorizzato ad usare una libreria GPL con collegamento dinamico se sto sviluppando su un motore di runtime proprietario? Fornire il contesto nel nome della classe, anche se lo spazio dei nomi fornisce il contesto

score 1 · Answer 1

Trovo la struttura migliore, se puoi chiamarla così,

Library
LibraryTests
    ClassATests.cs
    ClassBtests.cs



public class ClassATests
{
    [TestCase(1, 2, Category="Integration")]
    [TestCase(3, 4, Category="Unit")]
    public void MethodC(int input, int expectedResult)
    {
        //SetUp
        //create unit or integration setup of object under test
        Console.Write("given " + input);
        //Call
        Console.Write("when whatever");
        //Assert
        Console.Write("then" + result);
    }
}

Ovviamente questo è un semplice esempio, puoi migliorarlo avendo nomi e dati guidati dai dati, ma ha diversi vantaggi.

Puoi eseguire facilmente tutti i test per un determinato progetto di libreria
Puoi eseguire facilmente tutti i test per una determinata classe
Puoi eseguire lo stesso test sia in unità che in sapori di integrazione
L'output della console verrà visualizzato nel risultato del test, in modo da poter ottenere informazioni dettagliate sugli errori
Test basati sui dati ti consentono di testare molti scenari con lo stesso codice
Quando si modifica una classe esistente è sempre evidente allo sviluppatore dove si trovano i test esistenti e dove dovrebbero aggiungere nuovi test.

I problemi che trovo con le strutture di test complicate, che coinvolgono l'ereditarietà e GivenThenQuando il naming è che di solito è una struttura inventata personalizzata piuttosto che uno standard di Visual Studio.

Ciò lo rende intrinsecamente più difficile per uno sviluppatore, che ha solo una piccola modifica da apportare o bug da correggere per capire come aggiungere un nuovo test. Prima devono capire il tuo sistema di test.

Inoltre, una volta capito ci sono spesso una grande quantità di codice da scrivere, nuovi file e classi aggiunte ecc. prima che un nuovo test possa essere aggiunto, come indicato in quello che potrebbe essere un caso di test a linea singola nel progetto sopra.

The GivenThenQuando la denominazione di classi e metodi, spesso funziona solo con particolari configurazioni di test runner. Se non hai questa configurazione, vedrai solo un sacco di WhenXisY senza informazioni su cosa sta realmente accadendo.

In breve, il vantaggio di vedere l'output GivenWhenThen è più che compensato dal costo della codifica aggiuntiva e dalla difficoltà di scrivere nuovi test.

In una vasta base di codice per alcuni anni potresti scoprire di avere a disposizione più sistemi di test inventati mentre le persone migliorano e modificano quello che è considerato un buon sistema nel tempo. Ho lavorato in luoghi in cui hanno utilizzato più lingue oltre a framework di test, runner e sistemi di simulazione in diversi componenti.

'Conoscere la struttura del test' non è più una cosa semplice. Potrebbe essere necessario scoppiare una versione non supportata di ruby, scoprire che gem gem ha scritto prima di partire per farlo funzionare con c # e quindi controllare le vecchie jiras per scoprire come farlo funzionare con team city