Presupposti : ogni codebase di prodotti si trova in un repository separato. Se il codebase del prodotto fosse un repo mono, sarebbe un gioco da ragazzi semplicemente metterli insieme.
Presupposti : i test di integrazione in questo contesto includono test di livello UI end-to-end (ad esempio Selenium) e test di livello API end-to-end (ad esempio GraphQL / Rest). I test richiedono servizi di corsa reali.
Mono Test Repo Pros :
- Framework di test condivisi (si applica sia ai test dell'interfaccia utente sia a quelli delle API)
-
Librerie di report condivise per test
-
File di configurazione condivisi (ad esempio vari set di configurazione del browser per i test dell'interfaccia utente)
-
L'installazione / rimozione dell'interfaccia utente può riutilizzare parti del framework di test dell'API (ad esempio, un test dell'interfaccia utente può utilizzare un / create endpoint per un'impostazione più rapida dei dati)
-
Facile da integrare in CI
git clone monorepo && ./monorepo/run-test.sh --tags=[YourProduct](questo è semplicistico, ma un'idea simile) -
Facile ottenere report di test che aggregano tutti i tuoi prodotti (o combinazioni di essi), senza strumenti esterni (ad es.
./monorepo/run-test.sh --tags=*- di nuovo, anche eccessivamente semplificato) -
Facile aggiungere nuovi prodotti. Basta creare una nuova cartella di prodotto, tag e utilizzare le variabili di contesto iniettate dipendenza nei test (ad esempio Browser Client, client API, ecc.)
Mono Test Rep Rep. :
-
Disaccoppiato dalla base di codice, non giace più vicino a codebase
-
Se costruito male, una modifica in un framework di test condiviso può influire sui test di altri prodotti
Sembra un disastro, ma ci sono molti più pro che contro. Quali sono altri Cons contro questo? Consiglieresti mai o addirittura prendere in considerazione questo approccio? Perché o perché no?