Wann werden Komponententests ausgeführt?

Question

Wir bauen derzeit unseren Build-Prozess in einer automatisierten, kontinuierlichen Integrationsumgebung auf und stellen uns der fundamentalen Frage, wann Unit-Tests durchgeführt werden sollen.

Eine Möglichkeit wäre, den Komponententest mit jeder Build-Task auszuführen. Sobald also ein Komponententest fehlschlägt, schlägt der gesamte Build fehl. Dies hat den Vorteil, dass der Entwickler immer gezwungen ist, die Unit-Tests grün zu halten, da er sonst die Applikation nicht ausführen kann. Auf der anderen Seite sind Sie immer abgelenkt, wenn Sie die Tests während eines Entwicklungsprozesses reparieren - was Sie zwingt, in sehr kleinen Iterationen zu arbeiten. Außerdem wird die Zeit für die Ausführung Ihrer Anwendung immer größer, da Sie jedes Mal auf die Tests warten müssen. Der andere Weg wäre, den CI-Server nach jedem neuen Commit die Tests durchführen zu lassen und den Entwickler einfach wissen zu lassen, dass etwas schief gelaufen ist. Auf diese Weise ist der Entwickler ziemlich frei, wann er sich um die Komponententests kümmern muss, aber auch andere Entwickler in der gleichen Branche können darunter leiden, weil sie nicht sicher sein können, dass alle Teile der Software wie erwartet funktionieren und überprüft werden müssen selbst, wenn die versagenden Tests auch ihre Arbeit beeinflussen könnten.

Haben Sie also Best Practices oder Empfehlungen, was wäre eine gute Zeit, um die Tests durchzuführen?

BTW: natürlich laufen auch größere Integrationstests, die in einem separaten CI-Prozess abgewickelt werden.

Answer 1

Ihr Build-Prozess sollte zwei Ziele haben: Build und Test. test sollte das Standardziel sein, wenn nichts anderes angegeben wird. Der Test kann erst ausgeführt werden, nachdem das Projekt erstellt wurde. Daher ist das Build-Ziel eine Testabhängigkeit. Also (nehmen Sie an, verwenden Sie make): make oder make test wird bauen und testen. make build wird nur das Projekt erstellen.

Wenn Sie jetzt eine IDE verwenden, können Sie den Test auf eine andere Art und Weise "außerhalb" der IDE durchführen. Also, fügen Sie vielleicht ein drittes Ziel ide hinzu und lassen Sie die Idee dieses bauen. Es könnte dann das Build-Ziel als normale Abhängigkeit haben und als letzten Schritt einen neuen Job im Hintergrund spawnen, um das Testen in seinem eigenen Terminal-Fenster durchzuführen, etwa (unter Linux): (xterm -e ./run-tests &).

Und wenn Sie außerhalb einer Idee (wie ich) entwickeln, dann haben Sie nur ein separates Terminal führen Sie den Build & Test. Sobald der Test beginnt, wissen Sie, dass der Build-Prozess abgeschlossen ist, so dass Sie Ihre Anwendung bereits ausführen können, auch wenn die Tests noch ausgeführt werden.

Genau dies zu demonstrieren (und als Proof of Concept den Testlauf im Hintergrund dafür, dass) Ich habe gerade einigen trivialen Testfall:

bodo.c:

#include <stdio.h> 

int main(int argc, char * argv[]) { 
     printf("Hallo %s", argc > 1 ? argv[1] : "Welt"); 
     return 0; 
} 

Makefile:

test: build run-tests 

ide: build run-tests-background 

run-tests-background: 
     (xterm -e ./run-tests --wait &) 

run-tests: 
     ./run-tests 

build: bodo 

bodo: bodo.o 

bodo.o: bodo.c 

.PHONY: run-tests run-tests-background 

Lauftests:

#! /bin/sh 

retval=true 
if test "$(./bodo)" != "Hallo Welt" 
then 
     echo "Test failed []" 
     retval=false 
fi 
if test "$(./bodo Bodo)" != "Hallo Bodo" 
then 
     echo "Test failed [Bodo]" 
     retval=false 
fi 
if test "$(./bodo Fail)" != "Hallo Bodo" 
then 
     echo "Test failed [Fail]" 
     retval=false 
fi 
sleep 5 # Simulate some more tests 
if $retval 
then 
     echo "All tests suceeded ;)" 
else 
     echo "Some tests failed :(" 
fi 
if test "$1" == "--wait" 
then 
     read -p "Press ENTER to close" enter 
fi 
if $retval 
then 
     exit 0 
else 
     exit 2 
fi 

Verbrauch:

Erstellen Sie das Projekt aber nicht laufen die Tests

make build 

Erstellen Sie das Projekt und führen Sie den Test in der aktuellen Terminal laufen

make 

Erstellen Sie das Projekt und den Test in separaten Terminal laufen. Machen Sie zurückkehren wird, sobald der Build-Prozess abgeschlossen und der Test wurde gestartet

make ide 

Und zwei Helfer, die nicht von Hand ausgeführt werden sollen: Nur die Tests in aktuellen Terminal laufen (dies fehlschlagen wird, wenn das Projekt noch nicht gebaut) wurde

make run-tests 

Nur die Tests in separatem Terminal läuft (dies wird fehlschlagen, wenn das Projekt noch nicht gebaut wurde). Marke wird sofort zurück

Answer 2

Kurze Antwort: Führen Sie alle Komponententests auf dem Build-Server für jedes Commit, in jeder Branche. Unter der Annahme, dass Ihre Unit-Tests nicht wirklich lange dauern, gibt es wirklich keinen Nachteil. Da alle Komponententests für jede Build-Aufgabe lokal ausgeführt werden, wäre das ein Overkill. Entwickler sollten die Disziplin haben, zu entscheiden, wann sie die Tests durchführen und wann nicht.

Sie möchten so schnell wie möglich wissen, wenn etwas nicht in Ordnung ist, damit Sie es sofort beheben können. Sie möchten auch alle Tests kennen, die fehlschlagen, und nicht nur den ersten fehlgeschlagenen Test. Wenn es mehrere Probleme gibt, wäre es ein ziemlich lästiger Arbeitsablauf, nur das eine Problem zu beheben und dann Commit, Push und warten zu müssen, dass der Build erneut ausgeführt wird, um zu sehen, ob es mehr Probleme gibt.