2013-06-04 16 views
11

Come posso saltare un test dell'unità BOOST? Vorrei saltare alcuni dei miei test di unità in modo programmatico a seconda (ad esempio) della piattaforma su cui li sto eseguendo. La mia soluzione attuale è:Come saltare un test dell'unità BOOST?

#define REQUIRE_LINUX char * os_cpu = getenv("OS_CPU"); if (os_cpu != "Linux-x86_64") return; 

BOOST_AUTO_TEST_CASE(onlylinux) { 
    REQUIRE_LINUX 
    ... 
    the rest of the test code. 
} 

(notare che il nostro ambiente di build imposta la variabile OS_CPU). Questo sembra brutto e soggetto a errori, e anche i silenziosi salti potrebbero far saltare i test agli utenti senza saperlo.

Come posso saltare in modo pulito i test dell'unità di spinta basati su una logica arbitraria?

risposta

2

Invece di saltarli, è possibile impedire di registrarli. Per raggiungere che è possibile utilizzare la registrazione test manuale di boost.test:

#include <boost/test/included/unit_test.hpp> 
using namespace boost::unit_test; 

//____________________________________________________________________________// 

void only_linux_test() 
{ 
    ... 
} 

//____________________________________________________________________________// 

test_suite* 
init_unit_test_suite(int argc, char* argv[]) 
{ 
    if(/* is linux */) 
     framework::master_test_suite(). 
      add(BOOST_TEST_CASE(&only_linux_test)); 

    return 0; 
} 

Vedi http://www.boost.org/doc/libs/1_53_0/libs/test/doc/html/utf/user-guide/test-organization/manual-nullary-test-case.html per ulteriori informazioni

Un'altra possibilità sarebbe quella di utilizzare #ifdef ... #endif con BOOST_AUTO_TEST_CASE. Quindi è necessaria una definizione definita se si sta compilando il codice sulla piattaforma di destinazione.

#ifdef PLATFORM_IS_LINUX 

BOOST_AUTO_TEST_CASE(onlyLinux) 
{ 
    ... 
} 
#endif 

Questa definizione può essere impostata ad esempio dall'ambiente di costruzione.

+0

non posso usare ifdefs, alcuni di questi criteri deve essere determinare in esecuzione in tempo. Probabilmente userò qualcosa come il tuo suggerimento di registrazione, grazie. – dbn

3

La registrazione manuale dei test è noiosa, noiosa e soggetta a errori. Se solo per piattaforma è necessario distinguere i casi di test, allora non compilerei semplicemente i casi di test irrilevanti sulle piattaforme in cui non hanno importanza configurando il mio sistema di build. In alternativa, è possibile utilizzare Boost.Predef che definisce i simboli del preprocessore necessari per tutto ciò che si desidera sapere sul sistema operativo, sul compilatore, ecc., Che consente di eseguire determinati test su #ifdef.

Infine, se questo criterio può essere conosciuto solo in fase di esecuzione ed è indipendente dalla piattaforma su cui si sta eseguendo, vorrei raggruppare i test che dipendono da particolari criteri in suite e regolare la riga di comando utilizzata dalla build per eseguire solo quelle suite in base ai criteri di runtime.

4

Utilizzare decoratori enable_if/enable/precondition.

boost::test_tools::assertion_result is_linux(boost::unit_test::test_unit_id) 
{ 
    return isLinux; 
} 


BOOST_AUTO_TEST_SUITE(MyTestSuite) 

BOOST_AUTO_TEST_CASE(MyTestCase, 
        * boost::unit_test::precondition(is_linux)) 
{...} 

precondizione viene valutata in fase di esecuzione, attivare, enable_if in fase di compilazione.

See: http://www.boost.org/doc/libs/1_61_0/libs/test/doc/html/boost_test/tests_organization/enabling.html

+0

Ottimo! Questo è esattamente quello che stavo cercando (indietro nel giorno). Lo controllerò con un paio dei nostri test. – dbn

+0

@Horus, c'è un modo per utilizzare un proiettore in una condizione preliminare? – mojo

+0

@mojo Puoi dare un'occhiata al mio codice https://github.com/precice/precice/blob/develop/src/testing/Testing.hpp. Uso un decoratore per rimuovere i test dall'albero di test, potrebbe funzionare anche per i proiettori. Tieni presente che il mio codice probabilmente utilizza API boost non ufficiale. – Horus

1

BOOST_AUTO_TEST_CASE(a_test_name,*boost::unit_test::disabled())

{ 
    ... 
} 
+0

Non trovo questo secondo parametro nella documentazione, sei sicuro che sia disponibile? – moodboom

+0

totalmente sì http: //www.boost.org/doc/libs/1_65_1/libs/test/doc/html/boost_test/tests_organization/enable.html – Sergei

+0

Grazie di cuore - e ora vedo che il tuo secondo parametro era in realtà un link ai documenti, doh. – moodboom

Problemi correlati