Sollte ich Systemtests in ein Frühjahrsprojekt einfügen?

Question

Mein Spring-Web-Projekt besteht aus:

.
1. util klassen;
2. Repositorys;
3. dienstleistungen;
4. Controller.

   Die Tests sind wie folgt:

   .
   1. Gerätests für Utem-Klassen;
   2. Spring-Integrationstests für Repositorys mit HSQLDB;
   3. Gerätests für Dienstleistungen mit Mock-Repositorys;
   4. Gerätests für Controller mit Mock-Services.

      Es können auch Systemtests sein, die die Gesamtprojektfunktionalität testen. Es kann mit einem externen Werkzeug wie Selen durchgeführt werden oder kann unter Verwendung von Federintegrationstests durchgeführt werden.

      Die Frage ist, sollte ich solche Spring Integration-Systemtests in ein Projekt einfügen oder sollten sie irgendwie getrennt werden?

      Ich sehe zwei Probleme, um Systemtests in einem Projekt einzuschließen: 1. Sie benötigen eine Konfigurationsabstimmung, da solche Tests nicht mit Produktionskonfiguration ausgeführt werden (z. B. Tests benötigen eine lokale DataSource, nicht der von JNDI); 2. Sie sind nicht autonom, sie brauchen einige externe Ressourcen und so weiter. Ich kann sie nicht nur als übliche Untertests ausführen.

      Wie organisieren Sie Ihre Systemprüfung?

Answer 1

Bei kleinen Projekten habe ich sie am selben Ort gehalten. Bei großen Unternehmensprojekten (die Art, für die Sie zum Beispiel den Frühling sinnvoll nutzen könnten) haben wir normalerweise Systemtests in einem separaten Paket / Projekt organisiert. Dies hilft, sie von der Hauptcodebase zu trennen.

Wenn Sie dies nicht tun, gibt es alle Arten von Versuchung, Klassen von dem Code wiederzuverweisen, um in etwas zu "helfen", das sich in etwas stärker auf die Erfahrung von Benutzern des Systems konzentrieren sollte (ein Benutzer kann ein anderes System sein ). Wenn dies geschieht, enden Sie mit der Kopplung zwischen den Projektdomänenklassen und der Benutzeroberfläche, wodurch der unvermeidliche Effekt ist, um ein Großteil der Logik zu duplizieren, wodurch sie in der realen Codebase entkoppelt werden können.

Das meiste Zeitpunkt, in dem die Logik in Systemszenarien tatsächlich auf Seiten, Bildschirmen, Web-Anrufe usw. konzentriert ist, ist der Wiederverwendung von Code aus dem Hauptprojekt ein roter Hering. Halten Sie die Pakete getrennt, um dieses Geschehen zu vermeiden, und denn sobald Sie es vermeiden, dass es passiert ist, müssen Sie sie nicht an derselben Stelle haben.

Stellen Sie jedoch sicher, dass die Systemtests in derselben Versionssteuerung wie der Code eingecheckt werden.

Wenn Sie noch keine kontinuierliche Integration und Prüfung / Bereitstellung tätigen, ist dies möglicherweise ein anderer Bereich, für den ein anderes Lernen Sie mit den Konfigurationsdateien hilft. Dieses Problem geht nicht weg, nur weil Sie in einem separaten Projekt in einem separaten Projekt haben, leider.