Risposta.

Un corretto versioning e integrazione dei test automatici sono fondamentali per garantire che le verifiche siano in linea con lo stato attuale del progetto.

Storia della questione

Inizialmente, i test automatici venivano spesso gestiti separatamente dal progetto principale, portando a incompatibilità e problemi di supporto. Lo sviluppo di più rami, i frequenti rilasci di software e test hanno generato la necessità di un sistema comune di controllo della versione.

Problema

Senza versioning e integrazione coordinata si presentano:

Esecuzione di test obsoleti su software modificato
"Rotture" dei test durante il rilascio di nuove funzionalità che non considerano le modifiche ai test
Malfunzionamenti nel CI/CD

Soluzione

L'approccio moderno:

I test sono conservati in un sistema di controllo delle versioni comune (spesso git)
Associazione del ramo di test al ramo di sviluppo del software: in una feature-branch, i test e il codice sono sviluppati insieme
Verifiche/compilazioni automatiche vengono eseguite tramite pull request
Revisione e approvazione delle modifiche ai test e al codice

# Approccio generale:
git checkout -b feature/new_login
# La funzionalità e i test sono sviluppati e testati insieme
# Dopo la revisione vengono fusi insieme nel ramo principale

Caratteristiche chiave:

Coerenza delle modifiche al codice e ai test (nessuna desincronizzazione)
Facile rollback e confronto delle versioni (tramite la cronologia git)
Possibilità di lavoro di squadra e code review dei test automatici

Domande insidiose.

È possibile conservare i test in un repository separato (dal codice del progetto)?

Sì, ma diventa più difficile mantenere i test aggiornati, è necessario un sync manuale, c'è il rischio di "dimenticare" di aggiornare qualcosa durante un rilascio o un bugfix.

I test devono coprire immediatamente tutte le nuove funzionalità al momento della creazione del PR?

Ideale — sì, in pratica spesso coprono MVP/scenari principali nel primo PR, mentre i casi complessi vengono gestiti in task separati. L'importante è che la funzionalità critica sia coperta immediatamente.

Si possono fare rollback solo delle modifiche ai test senza rollback del codice?

Se i test e il codice sono insieme in un unico ramo — sì, è possibile rollare le revisioni. Ma è meglio evitare di "rollare" i test senza il codice: ciò diminuisce la qualità della verifica.

Errori tipici e anti-patterns

Conservare i test non in git, ma nei file system
Gestire i test in un repository separato senza una chiara connessione con il progetto
Integrazione dei test esternamente (post factum), invece di contemporaneamente con il codice

Esempio dalla vita reale

Caso negativo

Progetto con un repository separato per i test automatici. Dopo il rilascio, gli sviluppatori "si sono dimenticati" di aggiornare i test — i test fallivano, venivano eseguite verifiche obsolete, i bug venivano scoperti in produzione.

Vantaggi:

Gli sviluppatori potevano lavorare senza dipendere dal QA

Svantaggi:

Perdite di tempo per la sincronizzazione, presenza di test "obsoleti"

Caso positivo

I test e il codice del progetto sono gestiti nello stesso ramo git: ad ogni nuova pull request i test automatici devono essere aggiornati per il codice aggiunto. Tutte le modifiche passano per la code review e controlli automatici.