Ich habe die letzten paar Tage nach den Antworten gesucht und konnte keine finden. Die nächste Antwort, die ich finden könnte, ist das was nicht genau die Fragen beantwortet, die ich habe.
Übrigens, ich habe ein Selenium-Testprojekt, das auf Gradle basiert. Wir bauen das Projekt auf Jenkins, führen die Tests in 20 gleichzeitigen Threads durch. Die Gesamtzahl der einzigartigen Testklassen, die ich habe, ist 87. Also erwarte ich, dass Gradle mindestens 5 Batches ausführt. Das Testprojekt wird unter Verwendung von JVM-Cucumber-Builds erstellt und löst Tests von Jenkins an Selenium Hub aus. Ich habe versucht, die Parallelität der Tests zu erhöhen, indem ich das Gitter so gut wie möglich nutze. Aber das Problem begann, als die Anzahl der Tests zu wachsen begann.
Als ich mit den Tests von Jenkins anfing, beobachtete ich zuerst den Test, der in allen 20 Testprozessen ausgeführt wurde, und ich sah, dass die zweite Charge ebenfalls mit derselben Menge an Prozessen gestartet wurde. Nach dem zweiten Batch gingen die Prozesse zurück in den Single-Modus und der gesamte Job dauerte 14 Stunden, um den Zweck der parallelen Testausführung zu vereiteln.
Großbuchstabeneigenschaften:
%Vor%CLI:
%Vor%Ich habe alle Dokumente gelesen, die ich finden kann, habe aber keine Antwort erhalten. Es wäre sehr zu begrüßen, wenn mir jemand bei diesen Fragen helfen könnte
1. Wie Gradle Batch den Test Runner intern? Wenn zum Beispiel 20 Executoren starten und 1,2,3 fertig ausgeführt werden, die schneller ausgeführt werden als die anderen, erhalten die drei Executoren drei weitere Testklassen oder warten auf die Ausführung des gesamten Batchs?
2. Kann forkJede Auswirkung auf die Ausführung während des parallelen Tests haben?
Jenkins Protokoll
Erfolgreich gestarteter Prozess 'Gradle Test Executor 6'
Erfolgreich gestarteter Prozess 'Gradle Test Executor 13'
Erfolgreich gestarteter Prozess 'Gradle Test Executor 14'
Erfolgreich gestarteter Prozess 'Gradle Test Executor 5'
Erfolgreich gestarteter Prozess 'Gradle Test Executor 16'
Erfolgreich gestarteter Prozess 'Gradle Test Executor 8'
Erfolgreich gestarteter Prozess 'Gradle Test Executor 19'
Erfolgreich gestarteter Prozess 'Gradle Test Executor 4'
Erfolgreich gestarteter Prozess 'Gradle Test Executor 2'
Erfolgreich gestarteter Prozess 'Gradle Test Executor 11'
Erfolgreich gestarteter Prozess 'Gradle Test Executor 10'
Erfolgreich gestarteter Prozess 'Gradle Test Executor 18'
Erfolgreich gestarteter Prozess 'Gradle Test Executor 1'
Erfolgreich gestarteter Prozess 'Gradle Test Executor 20'
Erfolgreich gestarteter Prozess 'Gradle Test Executor 7'
Erfolgreich gestarteter Prozess 'Gradle Test Executor 9'
Erfolgreich gestarteter Prozess 'Gradle Test Executor 3'
Erfolgreich gestarteter Prozess 'Gradle Test Executor 15'
Erfolgreich gestarteter Prozess 'Gradle Test Executor 17'
Erfolgreich gestarteter Prozess 'Gradle Test Executor 12'
Gradle Test Executor 13 hat mit der Ausführung von Tests begonnen.
Gradle Test Executor 14 hat mit der Ausführung von Tests begonnen.
Gradle Test Executor 6 begann Tests auszuführen.
Gradle Test Executor 5 begann Tests auszuführen.
Gradle Test Executor 16 hat mit der Ausführung von Tests begonnen.
Gradle Test Executor 19 begann Tests auszuführen.
Gradle Test Executor 8 hat mit der Ausführung von Tests begonnen.
Gradle Test Executor 4 hat mit der Ausführung von Tests begonnen.
Gradle Test Executor 2 hat mit der Ausführung von Tests begonnen.
Gradle Test Executor 10 hat mit der Ausführung von Tests begonnen.
Gradle Test Executor 11 hat mit der Ausführung von Tests begonnen.
Gradle Test Executor 18 startete die Ausführung von Tests.
Gradle Test Executor 1 hat mit der Ausführung von Tests begonnen.
Gradle Test Executor 20 startete die Ausführung von Tests.
Gradle Test Executor 7 begann Tests auszuführen.
Gradle Test Executor 3 hat mit der Ausführung von Tests begonnen.
Gradle Test Executor 9 begann mit der Ausführung von Tests.
Gradle Test Executor 17 begann Tests auszuführen.
Gradle Test Executor 15 hat mit der Ausführung von Tests begonnen.
Gradle Test Executor 12 hat mit der Ausführung von Tests begonnen.
Der Standardwert von forkEvery ist 0
Laut der Dokumentation forkEvery ist
Die maximale Anzahl von Testklassen, die in einem gegabelten Testprozess ausgeführt werden. Der gegabelte Testprozess wird neu gestartet, wenn dieses Limit erreicht ist. Der Standardwert ist 0 (kein Maximum).
Also wird Gradle (und wahrscheinlich Junit) nach Klassen und nicht nach Tests innerhalb der Klasse verzweigen. Es hört sich so an, als ob einige der 87 Testklassen lange Tests oder eine große Anzahl von Tests durchlaufen haben und sie in einem gegabelten Testprozess enden. Ich würde in Erwägung ziehen, forkEvery auf 1 zu setzen. Dadurch wird sichergestellt, dass jede Testklasse an eine neue Verzweigung gesendet wird. Wenn es immer noch ein Problem gibt, müssen Sie möglicherweise herausfinden, welche Testklassen die meiste Zeit benötigen. Ziehen Sie in Betracht, diese Klassen in kleinere Gruppen von Tests aufzuteilen, damit die Tests über jedes jvm verteilt werden. Wenn es ein Test ist, der ewig dauert, sollten Sie ihn neu entwerfen und möglicherweise kleinere Tests daraus erstellen.
Ich glaube nicht, dass Gradle Tests in Batches ausführt. Wenn ein Mitarbeiter verfügbar wird, nimmt er eine Testklasse aus der Warteschlange der verbleibenden Tests. Du müsstest wirklich schauen, wie JUnit funktioniert, da ich sicher bin, dass Gradle diese Konfigurationen einfach an JUnit übergibt.
Tags und Links java gradle groovy selenium build.gradle