Ho letto molto sui framework di testing delle unità .NET disponibili. Ciò che non mi è chiaro sono quali sono le caratteristiche chiave che differenziano i quadri disponibili. Quali sono le funzionalità indispensabili che si cercano quando si valutano i framework di test delle unità?Framework test unità - Quali sono le funzionalità principali
Sono d'accordo che sono tutti abbastanza simili quando si tratta di asserzioni e altre caratteristiche di base. Dove iniziano a differenziarsi è in opzioni più avanzate, come framework di scripting, strumenti di compilazione, integrazione automatica, ecc.
Se si intende eseguire un processo di compilazione altamente automatizzato utilizzando qualcosa come CruiseControl.NET con un sacco di build personalizzate opzioni e scritpting personalizzato probabilmente userò NUnit. Esistono molti più hook per l'attivazione di altre azioni in base ai risultati del test.
Se si sta appena iniziando con i test delle unità e si pianifica solo di eseguire test di integrazione di base, mi attenersi a MStest per la sua stretta integrazione con Visual Studio 2008. (NUnit ha opzioni per l'integrazione con l'IDE ma il costo degli strumenti migliori . soldi)
Qui è un po tabella di confronto:
| NUnit | MStest
---------------------------------------------------------------------------------
Asserts | missing some collection asserts | missing some numeric/date asserts
---------------------------------------------------------------------------------
Speed | test run fast, faster setup on | w/ VS 2008 no setup necessary on
| servers and the like | the client, test run fairly fast.
---------------------------------------------------------------------------------
Options | a lot of 3rd party add-ons and | some 3rd party tools
| other tools |
---------------------------------------------------------------------------------
CC.NET | good integration, lots of tools | newer versions of CC.NET support
| and options | MS test out of the box, not as
| | many add on tools
---------------------------------------------------------------------------------
Tutti fanno la stessa cosa, e se non lo fanno, hanno punti di estensione che significano che è possibile ottenere la stessa cosa. E in questo senso, è possibile valutarli in base agli stessi criteri utilizzati per la scelta di qualsiasi framework (ad esempio popolarità (NUnit), MS-Certiffied (MS-Test) ecc.)
Tuttavia, se si desidera un consiglio sulla scelta uno, ti suggerisco di leggere sulla pagina XUnit "why did we build xunit" che indica alcuni dei problemi che circondano i framework di test delle unità.
Se si desidera vedere alcune somiglianze tra tutti i framework, è possibile vedere dalla tabella here, tutti hanno molte caratteristiche simili, solo parole diverse per le cose.
Ovviamente la scelta di un quadro BDD è un diverso bollitore di pesce.
Qui ci sono alcune cose che cerco
Assert.Throws? Gli assert sono in grado di fare confronti numerici con una tolleranza specificata?La cosa che cerco è il supporto di strumenti, con la mia priorità particolare di supporto per l'integrazione continua. La parte più importante dei test unitari (almeno per me, non essendo un grande fan di TDD) è quella di collegarli al mio server di build CI.
Per questo motivo, preferisco nUnit, poiché in CruiseControl sono presenti attività di compilazione predefinite, che è il mio server di scelta. Ciò non vuol dire che non sia possibile collegare nessun altro framework di testing in CC, nUnit sembra essere facile da usare.
Per quanto riguarda le funzionalità disponibili, MSTest ha alcuni componenti aggiuntivi davvero carini quando lo si esegue con il fantastico sistema di Visual Studio Team System con TFS nel back-end.
Detto questo, non c'è davvero molta differenza nella funzionalità dei singoli framework di test (ho esperienza con xUnit, nUnit e MSTest) - tutti consentono di definire i test unitari e riportano come sono passati e quanti hanno fallito. Hanno tutti una sorta di GUI, ed è possibile integrarli tutti con i build server.
una cosa che mi manca in quasi ogni quadro test è affermazioni uniformi, e con questo intendo che i test dovrebbero guardare th lo stesso indipendentemente da ciò che sto affermando. Se faccio asserzioni basate sullo stato su un valore, asserzioni basate sul comportamento su un mock o asserendo che un'eccezione dovrebbe essere generata.
Ho intenzione di usare Ruby come esempio, ma questo vale per qualsiasi ambiente. (E, BTW, non si è limitato a C# framework per testare le applicazioni .NET, è possibile utilizzare qualsiasi linguaggio NET, di cui Rubino, naturalmente, è uno, come lo sono Python, Scheme, F #, ...)
Questo è test/unit (una porta di una versione precedente di JUnit) con Mocha per il mocking.
def test_state
assert_equal 2, 1+1
end
def test_exception
assert_raises(NoMethodError) { [].not_a_method }
end
def test_behavior
o = Object.new
o.expects(:ping).with(:pong)
o.ping(:pong)
end
nota come tutte le asserzioni aspetto diverso e sono in un luogo diverso e il codice di prova reale è in tre differenti posto pure.
E questo è Aspettative, che AFAIK è l'unica struttura che fa bene. (In effetti, è stato creato appositamente per le asserzioni uniformi.) Sfortunatamente, non è più mantenuto o supportato in quanto l'autore non sta più facendo alcun lavoro su Ruby.
expect 2 do
1+1
end
expect NoMethodError do
[].not_a_method
end
expect Object.new.to.receive(:ping).with(:pong) do |o|
o.ping(:pong)
end
Si noti come le affermazioni sembrano sempre lo stesso, e sia le affermazioni e il codice di prova sono sempre nello stesso punto.
I framework più recenti, come xUnit.Net e Mockito, si stanno sicuramente avvicinando.
test di unità di sviluppo rivolto (notare che io non parlare di test di accettazione rivolti ai clienti!) Sono come codice di produzione: essi devono essere scritti in modo tale che sia evidente quello che stanno facendo. In effetti, questo è ancora più importante per i test che per il codice di produzione, perché con il codice di produzione hai i test per dirti se il codice funziona o no, con i test, tutto ciò che hai è leggerli e vedere se hanno senso o non.
Pertanto, i test di unità rivolti allo sviluppatore non dovrebbero richiedere commenti. E i nomi dei test sono, quindi il tuo framework non dovrebbe obbligarti a nominare i tuoi test.
Ecco un esempio (in RSpec, che ovviamente può essere utilizzato anche su NET, questa volta):
describe Array do
it 'should be empty' do
Array.new.should be_empty
end
end
Questo è solo stupido. Qualsiasi sviluppatore che ha bisogno di un nome di test per capire cosa sta facendo questo test dovrebbe seriamente ripensare alla sua scelta professionale. Inoltre, si applicano tutti gli stessi problemi con i commenti: cosa succede se qualcuno cambia il test ma si dimentica di cambiare il nome? Ora il nome non è solo inutile, ma anche fuorviante!Questo è molto meglio:
describe Array do
it do
Array.new.should be_empty
end
end
RSpec ha un altro trucco ingegnoso nella manica: si crea automaticamente un'istanza della classe che si sta testando per voi, in modo che non c'è bisogno di dire che ClassUnderTest.new.should ancora e ancora, si può solo dire should:
describe Array do
it { should be_empty }
end
E, a proposito, proprio come uno sviluppatore può capire di cosa si tratta di test, in modo da può RSpec. Questo è ciò che sputa fuori in tutti e tre i casi se si chiede per un riassunto cliente leggibile della suite di test:
Array
- should be empty
La tabella manca importante fila (a LEA per me) - integrazione con TFS – PiRX