Qual è il framework più aggiornato più aggiornato in .NET per la scrittura dei test di accettazione?

Question

Sto praticando TDD da qualche tempo, voglio portare avanti le mie capacità e iniziare a fare ATDD, ho letto di framework per Ruby e Java, ma non ho sentito molto su .NET

Qual è il più nuovo più mantenuta framework in .NET per scrivere test di accettazione?

MODIFICA: Dopo aver letto di più, desidero notare che stavo relazionando ai test di accettazione per i siti Web e l'applicazione sul Web, forse è necessario considerare anche i test della GUI.

Answer 1

Abbiamo appena iniziato a utilizzare FitNesse e finora sono soddisfatto della decisione. Una breve panoramica:

1. Scrivi i tuoi test in un Wiki.
2. Si scrive un modulo 'test fixture' (che può essere un assembly C#) che fornisce il ponte tra i "test" nel Wiki e il SUT (System Under Test).
3. Quando si eseguono i test, il motore di FitNesse utilizza il riflesso per tradurre i test wiki in chiamate all'assieme di dispositivi di prova, che a sua volta chiama SUT. I valori di ritorno vengono passati al Wiki in modo da poterli "asserire".

L'interfaccia pubblica del codice del dispositivo di prova è in effetti la lingua utilizzata per scrivere i test nel Wiki. Non sono sicuro di averlo spiegato molto bene, ma ci sono molte risorse e video sul web. Raccomando this one da Bob Martin, autore di FitNesse.

ho scelto FitNesse per una serie di motivi:

• consolidate quadro
• opere con .NET utilizzando FitSharp plugin: http://fitnesse.org/FitNesse.DotNet
• perché i test del Wiki sono scritti nella lingua di definire nel tuo codice apparecchio, sono leggibili
• test possono essere chiamati tramite riga di comando, che vogliamo per l'integrazione continua.
• Robusto 1: se l'interfaccia del SUT cambia, è necessario solo modificare il codice del dispositivo di test, non i test
• Robusto 2: non stiamo testando il livello dell'interfaccia utente volatile.

Ci vuole un po 'di tempo per abituarsi, ma lo trovo molto più affidabile del nostro attuale concetto di test attraverso l'interfaccia utente. Lo facciamo al momento in un'applicazione home-brew, che funziona riproducendo le azioni dell'interfaccia utente preregistrate e confrontando le schermate. Quando i test sono rossi, è raro che il SUT sia effettivamente rotto. In genere abbiamo problemi di temporizzazione con i controlli dell'interfaccia utente che non reagiscono all'istante, quindi dobbiamo creare ritardi tra le azioni dell'interfaccia utente, il che significa che impiega tutta la notte per eseguire l'intera suite di test.

Answer 2

mSpec (specifiche della macchina) è un framework TDD/BDD molto popolare.

nUnit è un quadro di test unitario (che può essere utilizzato anche per il test di accettazione ).

Answer 3

Si prega di considerare Ranorex come uno degli strumenti abbastanza nuovi.

http://www.ranorex.com/

fanno un ottimo lavoro nel fornire un set completo di strumenti che include il test api unità, motore di automazione e un registratore di prova. In breve - scrivi i tuoi test in C# o "li registra" usando il registratore e il registratore li scrive come codice C#.

Quindi li "rispondi", eseguendo il codice C#. Crei tutti gli asser che vuoi e l'API di automazione ti consente di automatizzare qualsiasi cosa visibile sullo schermo.

Ottimo strumento per ATDD, lo usiamo da tempo e siamo soddisfatti.