Dovrei includere i test di sistema in un progetto di primavera?

Question

Il mio progetto Web Spring è composto da:

.
1. classi Util;
2. repository;
3. Servizi;
4. controller.

   I test sono i seguenti:

   .
   1. Test dell'unità per classi Util;
   2. test di integrazione della molla per i repository con HSQLDB;
   3. Test dell'unità per servizi con repository finali;
   4. Test dell'unità per i controller con servizi finali.

      Ci possono anche essere test di sistema che testano la funzionalità complessiva del progetto. Può essere eseguito con uno strumento esterno come il selenio o può essere eseguito utilizzando il test di integrazione della molla.

      La domanda è, dovrei includere tali test del sistema di integrazione primaverile in un progetto o dovrebbero essere separati in qualche modo?

      Vedo due problemi di cui includendo i test di sistema in un progetto: 1. hanno bisogno di una sintonizzazione della configurazione perché tali test non funzionerà con la configurazione di produzione (ad esempio i test hanno bisogno di un datasource locale, non quello di JNDI); 2. Non sono autonomi, hanno bisogno di alcune risorse esterne e così via. Non riesco a gestirli come usuali test unitario.

      Come organizzi il test del sistema?

Answer 1

Su piccoli progetti li ho tenuti nello stesso posto. Su progetti di grandi imprese (il tipo per il quale potresti utilizzare utilmente la molla, ad esempio) di solito abbiamo organizzato test di sistema in un pacchetto / progetto separato. Questo aiuta a tenerli separati dalla tabella di codice principale.

Se non lo fai, c'è tutti i tipi di tentazione per riutilizzare le classi dal codice per "aiutare" in qualcosa che dovrebbe essere più fortemente focalizzato sull'esperienza degli utenti del sistema (un utente potrebbe essere un altro sistema ). Se ciò succede, si finisce con il giunto tra le classi di dominio del progetto e l'interfaccia utente, che avrà l'inevitabile effetto di aver bisogno di duplicare gran parte della logica che aiuta a mantenerli disaccoppiati nel vero codebase.

La maggior parte del tempo in cui la logica negli scenari di sistema sarà effettivamente focalizzata su pagine, schermate, web-chiamate, ecc. Quindi il codice di riutilizzo del progetto principale è un'aringhe rossa. Tenere i pacchetti separati per evitare questo accadimento, e perché una volta evitato che accada, non è necessario averli nello stesso posto.

DO, tuttavia, assicurarsi che i test di sistema vengano verificati allo stesso controllo della versione del codice.

Se non stai ancora facendo integrazione continua e test / implementazione, potrebbe essere un'altra area per la quale un po 'di apprendimento ti aiuterà con i file di configurazione. Quel problema non va via solo perché hai prove in un progetto separato, purtroppo.