Führen Sie Komponententests in Jenkins / Hudson automatisch von Dev zu Build Server durch

8

Wir betreiben derzeit einen Jenkins (Hudson) CI-Server, um unsere .net-Webprojekte und Datenbankprojekte zu erstellen und zu paketieren. Alles funktioniert gut, aber ich möchte beginnen, Komponententests zu schreiben und dann nur den Build zu übergeben, wenn die Komponententests bestanden werden. Wir verwenden die integrierte msbuild-Aufgabe, um das Webprojekt zu erstellen. Mit folgenden Argumenten ...

%Vor%

Wir müssen automatische Tests über unseren Code ausführen, die automatisch ausgeführt werden, wenn wir auf unseren Maschinen aufbauen (Postbuildereignis möglicherweise), aber auch ausgeführt werden, wenn Jenkins einen Build für dieses Projekt erstellt.

Wenn Sie es so ausführen, wird das Unit-Tests-Projekt nicht erstellt, da das Webprojekt nicht auf das Testprojekt verweist. Das Testprojekt würde auf das Webprojekt verweisen, aber ich bin mir ziemlich sicher, dass dies unsere automatisierten Builds abschlachten würde, da sie hauptsächlich dazu dienen, unsere Bereitstellungen zu erstellen und zu paketieren. Das Ausführen dieser Tests sollte ein Schritt in diesem automatisierten Build- und Paketprozess sein.

Optionen ...

  1. Erstellen Sie zwei Jenkins-Jobs. eine, um die Tests auszuführen ... Wenn die Tests bestanden werden, wird ein anderer Build ausgelöst, der das Webprojekt erstellt und packt. Setzen Sie das Postbuildereignis auf das Testprojekt.
  2. Erstellen Sie die Lösung anstelle des Projekts (vergewissern Sie sich, dass die Lösung die erforderlichen Tests enthält), und schreiben Sie nach dem Erstellen Ereignisse für alle Testprojekte, die die nunit-Konsole ausführen, um die Tests auszuführen. Verwenden Sie dann die Befehlszeile, um alle erforderlichen Dateien aus den Verzeichnissen bin und content in ein Paket zu kopieren.
  3. Erstellen Sie einfach das Testprojekt in Jenkins statt des Webprojekts in Jenkins. Das Testprojekt würde auf das Webprojekt verweisen (abhängig davon, was Sie testen) und es erstellen.

Probleme ...

  1. Es gibt zwei Jobs und nicht einen. Zwei Dinge, um nicht einen zu debuggen. Eine um zu sehen, ob die Tests bestanden und eine um das Webprojekt zu erstellen und zu kompilieren. Die Tests können bestanden werden, aber der Build kann fehlschlagen, wenn etwas nicht von dem verwendet wird, was Sie testen ...
  2. Dies erfordert, dass wir genau wissen, was in den Build hineingeht. Genau jetzt macht msbuild alles für uns. Wenn mehrere Teams an einem Projekt arbeiten, jedes Mal, wenn ein zusätzlicher Ordner erstellt wird, müssen Sie sich über die möglicherweise spröden Befehlszeilenanweisungen Gedanken machen.
  3. Das scheint hier eine Verfälschung unseres Hauptzwecks zu sein. Die Tests sollten ein Schritt in diesem Prozess sein und nicht das Wichtigste in diesem Prozess. Ich bin auch nicht 100% sicher, dass ein ausgelöster Build der gleiche wie ein normaler Build ist, macht es die gleichen Dinge wie ein normaler Build. Verschieben Sie alle korrekten Dateien auf die gleiche Weise, verschieben Sie sie alle in die gleichen Verzeichnisse usw.

Anfangsproblem.

Wir möchten unsere Tests immer dann durchführen, wenn unser Hauptprojekt gebaut wird. Das Hinzufügen eines Post-Build-Ereignisses zum Webprojekt, das für das Testprojekt ausgeführt wird, funktioniert jedoch nicht, da das Webprojekt nicht auf das Testprojekt verweist und keinen Build dieses Projekts auslöst. Ich könnte weitermachen ... aber das ist genug ...

Wir haben ungefähr eine Woche damit verbracht, diese Arbeit gut zu machen, aber es ist nicht gelungen. Fühlen Sie sich frei, dies zu bearbeiten, wenn Sie glauben, dass Sie eine bessere Antwort bekommen können ...

    
Kevin Donde 24.10.2012, 19:10
quelle

1 Antwort

9

In Jenkins / Hudson ist es ziemlich in Ordnung, viele Jobs zu haben. einige für die Durchführung kompilierungsgesteuerter Versionskontrolländerungen, einige für das Ausführen von (Einheits-) Tests, die durch erfolgreiche Builds ausgelöst wurden, einige für mehr Tests (Integration), die durch erfolgreiche frühere Tests getriggert wurden, einige für das Deployment, ausgelöst durch erfolgreiche Tests.

Sehen Sie sich Plugins wie Join, Build-Pipeline, parametrisierter Trigger und mehr an, um Ihnen dabei zu helfen.

Dies ermöglicht auch, dass Dinge parallel passieren, indem mehrere Knoten verwendet werden. Der Versuch, alles in einem Job zu stopfen, ist nicht der richtige Weg.

    
hyde 25.10.2012, 10:57
quelle