Testing Framework Selection: teoria della famiglia xUnit

Ho scoperto che mentre un set di strumenti nella stessa famiglia può sembrare che dovrebbero essere tutti uguali (in particolare sto pensando a log4x, che è una libreria di log impressionante e molto meglio di cose come la .net logging stuff) è ancora abbastanza diverso nella sua configurazione e può essere utilizzato praticamente come strumenti separati.

Quindi non starei con una sola famiglia di strumenti e userei qualunque strumento ti sia piaciuto di più, indipendentemente dalla sua provenienza.

Trovo questo tipo di pensiero prevalente nel mondo Microsoft - "usiamo Microsoft qui" e non importa quanto sia pessimo lo strumento Microsoft, o quanto sia meraviglioso lo strumento non Microsoft, alcune persone semplicemente non usano il bene roba e resterà fedele a ciò che Microsoft offre loro. (Era lo stesso con IBM, e sono sicuro che altri posti hanno la stessa mentalità). Il problema qui è che si limitano all'idea che ci siano cose là fuori che sono effettivamente migliori.

Quindi usa gli strumenti che ritieni siano i migliori. Se voi (e tutti gli altri) rifiutaste di utilizzare un framework di test non xUnit, allora vi sarebbe un piccolo incentivo per le persone a trovare nuovi modi migliori per risolvere il problema. L'utilizzo del prodotto di migliore qualità è la migliore pratica del settore IMHO.

Non ho fatto TDD in C ++, ma attualmente sto leggendo Lavorare in modo efficace con il codice legacy e il mio primo istinto sarebbe di andare con qualcosa consigliato da Michael Feathers.

1. Nella mia esperienza sono i concetti che sono più importanti dei nomi delle cose. Quindi, nello stile xUnit, hai il concetto di una suite di test che contiene un gruppo di test, una procedura di configurazione e una procedura di rimozione. L'installazione viene eseguita prima di ogni test nella suite e il teardown viene eseguito dopo ogni test. Quindi qualsiasi framework con questi concetti dovrebbe essere facile per qualcuno con esperienza xUnit per adattarsi a

2. I test di integrazione sono una bestia diversa dai test unitari. I framework di stile xUnit non si concentrano veramente sull'integrazione. La gente del Web ha sviluppato strumenti specializzati che "autopilota" un browser Web per testare il comportamento del sito Web, ma credo che un approccio più generale sia preso da qualcosa come Fitnesse, che consente di specificare gli input e gli output previsti da un sistema e testarli sono soddisfatti.

   Dirò che vuoi tenere d'occhio gli strumenti automatici, specialmente per vedere se il tuo strumento di compilazione può comprendere l'output del tuo framework di test e presentarlo in rapporti, notifiche, ecc. È non abbastanza per un framework per stampare solo materiale sulla console - deve essere in grado di darti qualcosa che il tuo sistema di integrazione continua può usare per verificare la riuscita di build e test di pass / failure (es. Travis CI).

3. Non sono sicuro di averlo capito - sembra troppo generico. Ma vedi # 1.