Domanda

C'è un buon strumento per generare casi di test di unità dato dicono un NET o progetto Java, genera casi di test di unità in grado di coprire una copertura del codice quasi il 100%. Il numero di casi di prova potrebbe essere direttamente proporzionale alla complessità ciclomatica del codice (maggiore è l'annidamento di loop e condizioni maggiore è la complessità ciclomatica) in cui si generano maggiore è la complessità ciclomatica, maggiore è l'insieme di test. Non mi aspettavo di essere pienamente funzionale (per esempio ho intenzione di costruire l'unità di test ed eseguirlo dopo il suo stato generato), ma direi che si può avere uno stile di modello nel caso di test in cui si sta per modificare il caso che si adatta alle vostre esigenze previsti. Ma dovrebbe anche avere un metodo di impostazione e teardown corretta ed è abbastanza buono per rilevare se gli oggetti mock per unità di test dovrebbero essere utilizzati ci dovrebbe essere alcun dipendenze. Quindi, c'è uno strumento che esiste?

È stato utile?

Soluzione

Per .NET, Microsoft ha Pex che si spera andare mainstream per NET 4.0, insieme a . Mi raccomando di guardare il video del canale 9.

Mi sembra che questo genere di cose è molto buona per le classi molto data-driven - parser ecc, non riesco a vedere che mi piacerebbe molto spesso Iniziamo con esso, ma un utile strumento per avere nel vostro arsenale comunque.

Altri suggerimenti

Per C # (o .NET in generale), PEX potrebbe essere tale strumento. Si lavora a livello di IL, e tenta di forzare la sua strada in ogni ramo. E ha scoperto con successo una vasta gamma di insetti (nel BCL etc).

Anche se sembra contro-intuituve, si può anche essere interessati a quadri casuali generazione di test. La ricerca ha dimostrato che può essere altrettanto efficace nel trovare i bug di approcci sistematici basati sulla copertura, come lei suggerisce.

Randoop sia per .NET e Java. Funziona generando una sequenza più o meno casuale di chiamate di metodo e contratti assegni, incidenti ecc E 'completamente automatico.

Inoltre si consiglia di controllare alcuni altri strumenti di test casuale basato su QuickCheck , per esempio per Java, Scala, F #. che sono più simili a Pex, cioè si dà una specifica, o test di unità parametrizzata, e lo strumento verifica per un certo numero di argomenti di input generati.

Ho trovato che in questo modo "parametrizzata" di unit test di scrittura è in realtà molto più naturale in almeno il 60% dei casi, e trova molto altro bug.

Per Java, è possibile controllare EvoSuite , che è open source e attualmente attiva (dichiarazione di non responsabilità, io sono uno dei suoi collaboratori). Si veda anche relativi per un elenco di più strumenti .

Per Java, prova a JUnit-Tools . Ha proprio plugin di Eclipse con una buona documentazione.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top