7

Ich erstelle eine Website auf Schienen und nutze Travis-ci bisher für die kontinuierliche Integration. Ich probiere auch wercker für die kontinuierliche Integration und den Einsatz aus. Der Testschritt scheiterte an Wercker, weil er länger als 25 Minuten lief und mir aufgefallen ist, dass meine Tests aus irgendwelchen Gründen ungewöhnlich lange dauern.Wie lange ist zu lang für eine Testsuite?

Die Website, an der ich arbeite, ist umfangreich, aber nicht massiv. Ich teste mit rspec und capybara und verwende Webkit für Integrationstests. Ich schreibe ziemlich gründliche Integrationstests, um sicher zu gehen, dass ich jedes Feature abdecke. Auf travis-ci dauert der gesamte Prozess 25-30 Minuten (einschließlich der Installation des Bündels).

Dies könnte eine vage Frage für dieses Forum sein, aber trotzdem möchte ich einige Eingaben erhalten. Ist es inakzeptabel, Testsuites zu haben, die eine halbe Stunde oder länger laufen? Welche Test-Suite-Zeiten haben Sie normalerweise für eine Reihe von Integrationstests?

+0

hängt davon ab, wie groß die Module sind, die Sie testen –

+0

haben keinen Test gesehen, der so lange dauert, –

Antwort

9

Es ist normal, dass kommerzielle Websites Integrationstest-Suites haben, sogar gut gestaltete, die eine Stunde oder länger dauern würden, wenn sie in einem einzigen Prozess auf einem Entwicklungscomputer ausgeführt würden. Sie haben uns also keinen Grund gegeben zu denken, dass Sie zu viele Tests schreiben oder schreiben, so dass sie ungewöhnlich langsam laufen. Das ist jedoch viel zu lang, um zu erfahren, ob Ihr Commit gut war. Nach meiner Erfahrung ist eine halbe Stunde zu lang und 15 Minuten sind marginal; Wenn es so lange dauert, alle Tests auszuführen, wird die Person, die den Build ausgelöst hat, etwas anderes starten oder während der Ausführung des Builds davonlaufen und muss dann im Kontext wechseln oder wird nicht in der Nähe sein, wenn der Build unterbrochen wird. Längere Builds erhöhen auch die durchschnittliche Anzahl der Commits in einem Build, wodurch es schwieriger wird, Schuld zuzuweisen, wenn der Build unterbrochen wird.

Lassen Sie Ihr CI so schnell wie möglich erstellen. Großes Thema, aber ein paar Ansatzpunkte:

  • Die parallel_tests Juwel ist die Art und Weise Ihrer Suite (beide Unit-Tests und Gurke) so schnell wie möglich auf einem einzigen Box zu laufen (die nur Sie bekommen so weit , aber vielleicht ist das für jetzt weit genug).
  • Hier ist ein weiteres Juwel (das ich nicht benutzt habe) zum Spalten von Gurken Szenarien über Boxen: https://github.com/cloudcastle/cucumber_in_groups
  • Travis CI, CircleCI und vermutlich andere gehosteten kontinuierliche Integration Services Möglichkeiten bieten die Tests über Boxen aufgeteilt.

Es ist auch hilfreich, eine Unit-Test-Suite zu haben, die meisten oder alle Ihre Code abdeckt und läuft viel schneller als die Integrationstests (in Sekunden oder höchstens ein paar Minuten), so dass die meisten Fehler, bevor die gefangen werden Integrationstests laufen.

+0

Danke, das war sehr hilfreich! –