Unser aktuelles AngularJS-Projekt befindet sich seit etwa 2,5 Jahren in der Entwicklung, so dass die Anzahl der Unit-Tests enorm gestiegen ist. Wir neigen dazu, einen Abdeckungsgrad von nahezu 100% zu haben, was zu mehr als 4000 Unit-Tests geführt hat. Dazu gehören auch Service-Specs und View-Specs. Sie wissen vielleicht, dass AngularJS - wenn es ein wenig missbraucht wird - nicht für supergroße Anwendungen geeignet ist, aber da wir das Biest gezähmt haben und eine Anwendung mit mehr als 16.000 Zeilen hochleistungsfähigem AngularJS-Code haben, wollen wir die Kontrolle über den gesamten Entwicklungsprozess ohne Leistungseinbußen behalten.
Wir verwenden Karma Runner mit Jasmine, was für eine kleine Anzahl von Specs und zum Debuggen in Ordnung ist, aber die Ausführung der gesamten Testsuite dauert bis zu 3 Minuten auf einem 2.8Ghz MacBook Pro. Da wir unseren Code kontinuierlich testen, haben wir eine Lösung gefunden, um alle Unit-Tests in mehrere Shards aufzuteilen. Diese parallele Ausführung der Unit-Tests hat die Ausführungszeit erheblich verkürzt. Über die Details dieser Karma-Parallelisierung werden wir später in diesem Blog schreiben. Sharding hat uns sehr geholfen, wenn wir die gesamte Unit-Test-Suite ausführen wollen, d.h. wenn wir sie im Pre-Push-Hook verwenden, aber während der Entwicklung schnelle Rückmeldungen über die Abdeckung und fehlgeschlagene Specs (rot-grüne Tests) wünschen. Bei einem so langen Unit-Test-Zyklus, selbst wenn er parallel läuft, beschreiben viele unserer Entwickler die Specs, an denen sie arbeiten, so dass die Rückmeldung sofort erfolgt. Dies ist jedoch recht arbeitsintensiv und manchmal wird einVerfasst von

Frank van Wijk
Frank is a senior frontend consultant focusing on quality and maintainability.
Unsere Ideen
Weitere Blogs
Contact



