Kontinuierliche Integration mit GTest und Buildbot

Ich möchte einen Continuous Integration Server mit Buildbot und Gtest setzen. Ich habe bereits gelungen, die Umgebung einzurichten, die nach der Einheit Prüfschritt der folgenden Ausgabe führt: zu wissen vorhanden, umKontinuierliche Integration mit GTest und Buildbot

Running main() from gtest_main.cc 
[==========] Running 7 tests from 3 test cases. 
[----------] Global test environment set-up. 
[----------] 4 tests from VectorTest 
[ RUN  ] VectorTest.size_is_correct 
[  OK ] VectorTest.size_is_correct (0 ms) 
[ RUN  ] VectorTest.min_index 
[  OK ] VectorTest.min_index (0 ms) 
[ RUN  ] VectorTest.sort_is_correct 
[  OK ] VectorTest.sort_is_correct (0 ms) 
[ RUN  ] VectorTest.indices_of_smallest_are_correct 
[  OK ] VectorTest.indices_of_smallest_are_correct (0 ms) 
[----------] 4 tests from VectorTest (0 ms total) 

[----------] 2 tests from MatrixTest 
[ RUN  ] MatrixTest.NumberOfColumnsIsCorrect 
[  OK ] MatrixTest.NumberOfColumnsIsCorrect (0 ms) 
[ RUN  ] MatrixTest.NumberOfRowsIsCorrect 
[  OK ] MatrixTest.NumberOfRowsIsCorrect (0 ms) 
[----------] 2 tests from MatrixTest (0 ms total) 

[----------] 1 test from SparseMatrix 
[ RUN  ] SparseMatrix.IteratorIsCorrect 

[  OK ] SparseMatrix.IteratorIsCorrect (0 ms) 
[----------] 1 test from SparseMatrix (0 ms total) 

[----------] Global test environment tear-down 
[==========] 7 tests from 3 test cases ran. (2 ms total) 
[ PASSED ] 7 tests. 
[100%] Built target unit

ich buildbot möchte diese Ausgabe zu analysieren, um zu überprüfen, ob das Schlüsselwort PASSED ist wenn beim Komponententest etwas schief gelaufen ist.

Wissen Sie, wie man das macht?

Quelle

2016-06-07 Aleph

GoogleTest unterstützt XML-Ausgabe im JUnit-Format mit der Befehlszeilenoption --gtest_output, die die meisten CI-Systeme bereits parsen können.

Ich weiß nicht, ob Buildbot JUnit Parsing unterstützt oder nicht. Wenn nicht, ist es sicherlich einfacher, eine XML-strukturierte Ausgabe als die Standard-Klartextausgabe zu analysieren.

Quelle

2016-06-08 07:25:43

Danke Antonio. Ich werde die Dokumentation von Buildbot anschauen, um zu sehen, ob eine solche Analyse möglich ist. – Aleph

Warum überprüfen Sie nicht den Exit-Code des Testprogramms? Es wird ein Erfolgscode (0) sein, wenn die Tests bestanden werden und ein Fehler (normalerweise 1), wenn sie fehlschlagen.

Quelle

2016-06-08 07:42:59 VladLosev

Danke Vlad. Es ist nicht so klar für mich, warum der Exit-Code des Programms ein Fehlercode sein sollte, wenn ein Komponententest nicht bestanden wird. Zum Beispiel verhält sich CPPUNIT nicht so, soweit ich mich erinnern kann. Das Programm sollte nur dann einen Fehlercode zurückgeben, wenn im Programm ein Fehler aufgetreten ist, z. B. eine Ausnahme. Da jedoch erwartet wird, dass das Programm Erfolge und Fehler in Komponententests erkennt, kann nicht erwartet werden, dass es einen Fehlercode zurückgibt, wenn es feststellt, dass ein Komponententest fehlgeschlagen ist. Eigentlich hat das Programm die Arbeit gut gemacht. Es gelang ihm, den Testfehler zu erkennen. – Aleph

@Aleph es wird empfohlen, von main() Ergebnis von RUN_ALL_TESTS() zurückzugeben: https://github.com/google/googletest/blob/master/googletest/docs/V1_5_Primer.md#invoking-the-tests So normalerweise beenden Code bedeutet, dass alle Tests bestanden wurden oder nicht. Aber im Allgemeinen haben Sie recht - es ist Sache des Autors des Testprogramms, zu entscheiden, was der Exit-Code bedeutet. – rutsky

Kontinuierliche Integration mit GTest und Buildbot

Antwort

Verwandte Themen