Sto iniziando un progetto in cui voglio avere una copertura di test piuttosto approfondita, e ho il lusso di guidare la strategia di test. Ho optato per un piano realizzabile per i test unitari e ho anche deciso di utilizzare Gherkin per descrivere le funzionalità e una porta di Cucumber per eseguire gli scenari come test di accettazione end-to-end.
Il problema è che sento che c'è una lacuna tra questi due livelli. Posso testare tutte le mie unità da solo, e posso verificare che le mie funzioni funzionino, ma posso pensare ad altre cose che voglio testare.
Vengo anche da un altro progetto con test automatici (implementati male) che sono molto fragili e sono un incubo di manutenzione, l'obiettivo di questi test è di sostituire principalmente i test di regressione manuale. Scrivere più test mantenibili è un must, ma ad un livello più alto non sono sicuro che i nostri test siano quelli giusti.
Ad esempio, data un'applicazione web, diciamo che c'è un modulo per aggiungere un evento con date di inizio e fine. Come test end-to-end, possiamo confermare che puoi, in effetti, aggiungere un evento. Ma se la data di inizio è successiva alla data di fine, viene visualizzato un messaggio di errore e non penserei che il modo in cui viene gestito un errore di input utente banale appartenga a un file di funzionalità. D'altra parte, sembra esserci una strong convinzione che l'unità testata sull'interfaccia utente non ne valga la pena; al contrario, si dovrebbero eseguire test di integrazione automatici.
Quindi cosa devo fare per questo codice?
Eseguo un test unitario dei componenti relativi ai messaggi di errore in generale, così come che questo modulo sta per mostrarli e ignora l'automazione della loro effettiva apparizione? Devo fare quanto sopra e quindi automatizzare che un solo messaggio di errore da qualche parte mostri come previsto, e supponiamo che il resto funzionerà? Cerco di automatizzare ogni potenziale caso di errore diverso per ogni modulo?
Colpisce la via di mezzo dei test di integrazione, di cui sono diffidente. In base alla mia esperienza, il mantenimento di un gran numero di test di integrazione non sembra valere il valore. D'altra parte, c'è funzionalità al di sopra del livello dell'unità e al di sotto del livello di funzionalità che avrei idealmente testato, sia nell'interfaccia utente che al di fuori di esso. E sono preoccupato di quale tipo di sicurezza regredisca la regressione automatica se non sta colpendo tutto.
Sono perfettamente disposto a scrivere test di integrazione, ma nel contesto di quando scrivere test, quali test scrivere e quanti scrivere, qual è un buon approccio per affrontare questo problema?