quadro di prova per il test dei componenti

Question

Sto cercando un framework di test più adatto alle mie esigenze. Di seguito sono riportati i passi che ho bisogno di esibirsi durante il test automatizzato:

• setup (Ci sono alcuni file di input, che deve essere letto o copiato in alcune cartelle specifiche.)
• Execute (Esegui stand alone)
• Abbattere (Clean up per portare il sistema nel suo vecchio stato)

Oltre a questo voglio anche avere un po 'di intelligenza per assicurarsi che se un file .cc cambiato, tutti i test in grado di convalidare le modifiche deve essere eseguito.

Sto valutando PyUnit, CppUnit con scons per questo. Il pensiero di correre questa domanda per assicurarsi che sono sulla strada giusta. Potete suggerire altri strumenti framework di test? E quali altri requisiti devono essere considerati per selezionare quadro di prova giusto?

Answer 1

Dopo aver letto questo articolo http://gamesfromwithin.com/exploring -la-c-unit test-quadro-jungle qualche tempo fa sono andato per CxxTest.

Una volta che hai la cosa istituito (è necessario installare python per esempio) è abbastanza facile scrivere dei test (ero completamente nuovo per unit test)

Io lo uso sul posto di lavoro, integrato come un progetto di Visual Studio nella mia soluzione. Produce un'uscita cliccabile quando un test fallisce, ei test sono costruiti ed eseguito ogni volta che costruisco la soluzione.

Answer 2

googletest AKA GTEST non è peggio poi qualsiasi altro quadro unit test, ma può pure battere alcuni con la facilità d'uso. Non esattamente uno strumento per test di integrazione siete alla ricerca di, ma può essere facilmente applicato nella maggior parte dei casi. Questo wikipedia potrebbe anche essere utile per voi.

Ecco una copia di un campione sulla pagina del progetto GTEST:

#include <gtest/gtest.h>

namespace {

// The fixture for testing class Foo.
class FooTest : public ::testing::Test {
 protected:
  // You can remove any or all of the following functions if its body
  // is empty.

  FooTest() {
    // You can do set-up work for each test here.
  }

  virtual ~FooTest() {
    // You can do clean-up work that doesn't throw exceptions here.
  }

  // If the constructor and destructor are not enough for setting up
  // and cleaning up each test, you can define the following methods:

  virtual void SetUp() {
    // Code here will be called immediately after the constructor (right
    // before each test).
  }

  virtual void TearDown() {
    // Code here will be called immediately after each test (right
    // before the destructor).
  }

  // Objects declared here can be used by all tests in the test case for Foo.
};

// Tests that Foo does Xyz.
TEST_F(FooTest, DoesXyz) {
  // Exercises the Xyz feature of Foo.
}

Scons poteva prendersi cura di costruire la vostra .cc quando sono cambiati, GTEST può essere utilizzato per impostare e teardown i test.

Posso solo aggiungere che stiamo utilizzando GTEST, in alcuni casi, e un costume in-house framework per l'automazione di test in quasi tutti gli altri. Spesso è un caso con questi strumenti che potrebbe essere più facile da scrivere il proprio che cercare di regolare e ottimizzare qualche altro per soddisfare le vostre esigenze.

Una buona opzione IMO, ed è qualcosa che il nostro framework per l'automazione di test si sta muovendo verso, sta utilizzando nosetests , accoppiato con una libreria di routine comuni (come start / stop dei servizi, ottenere lo stato di qualcosa, abilitare / disabilitare la registrazione in alcuni componenti, ecc). Questo vi dà un sistema flessibile che è anche abbastanza facile da usare. E dal momento che utilizza python e non C ++ o qualcosa del genere, più persone possono essere occupate casi di test, tra cui la creazione Qes, che non necessariamente devono essere in grado di scrivere C ++.