Quando scrivere i test funzionali e di integrazione è troppo presto?

0

Se una funzionalità che è stata eseguita in 2, 3 mesi e prima che venisse unificata nel ramo principale, ed entrambi i rami erano costantemente modificati ogni giorno, in questa fase dovrebbero essere scritti i test di integrazione?

Sarà troppo presto, perché entrambi i rami stanno cambiando, l'interfaccia utente sta cambiando e anche le specifiche stanno cambiando. Se ai test di integrazione viene chiesto di essere sviluppati in questa fase, puoi aspettare che il test passi il Jenkins o se qualcuno è già fuso, quindi devi unire nuovamente i test di Integrazione continua per altre 2 ore e un giorno o due, il test avrà già esito negativo a causa di cose che cambiano così velocemente.

Sarebbe troppo presto? Sarebbe più appropriato se la codifica fosse finita e con il ramo della funzione unito al ramo principale, che i test di integrazione iniziassero a essere scritti?

Qualche moderatore chiude questa domanda dicendo: Possibile duplicato di Quanto deve essere grande per me il mio progetto per testarlo unitamente? Non è un duplicato. Questa domanda riguarda quando. Quella domanda ti sta chiedendo di quale dimensione.

    
posta 太極者無極而生 08.09.2017 - 08:47
fonte

1 risposta

4

È troppo presto per iniziare a scrivere i test quando le specifiche non sono ancora state scritte. Una volta che hai le specifiche dovresti iniziare a scrivere i test in attesa che il codice sia troppo tardi e non ti raggiungerai mai.

Idealmente i tuoi programmatori dovrebbero scrivere un codice che possa essere testato per verificare che soddisfi i requisiti di progettazione non appena pensano di aver finito e prima di iniziare a pensare di passare ad altre cose.

In pratica finirai comunque con la modifica e l'integrazione dei test durante la codifica, ma avrai qualcosa su cui lavorare.

Leggi su Test Driven Development ma gli stessi principi si applicano a quasi tutti gli altri flussi di lavoro.

Per chiarire - è del tutto possibile che gli autori delle specifiche, i codificatori e gli ampli; gli scrittori di test possono essere le stesse persone o anche la stessa singola persona, (come indicato da Doc Brown ma:

  • Se non disponi di una specifica fissa, emessa , non sai dove stai andando, quando sei arrivato lì o anche se ci sei arrivato - scrivendo o persino finalizzando la specifica dopo che il progetto è documentazione non specifica.
  • Senza una specifica chiara si è inclini alla funzionalità creep.
  • Ovviamente durante il corso di quasi tutti i progetti le specifiche cambieranno ma se hai una buona tracciabilità tra specifiche e test, intendi tu non conosci quale requisito questo test è per & quali test dimostrano che questo requisito è soddisfatto , quindi sai quali test devono essere aggiornati, lo stesso vale per il codice - hai anche un chiaro percorso per indicare la gestione quando il dithering delle specifiche e i cambiamenti tardivi stanno costando soldi (grazie a Bart van Ingen Schenau per averlo menzionato) e dovrebbe essere lasciato alla versione 2,3 ...
  • L'altro argomento per una buona tracciabilità è che quando una parte del codice non funziona, come dimostrato dai tuoi test, tu conosci quali caratteristiche saranno mancante se lo si disabilita semplicemente per questa versione.
  • Un auditor una volta mi ha detto che ogni volta che veniva presentata la specifica ed era al numero 1, sapevano che il progetto sarebbe stato un incubo.
  • Con il controllo delle modifiche sulle specifiche si ha una chiara registrazione di quali requisiti sono stati modificati, quando, da chi e si spera perché e con quanto impatto sulla codifica e test - quando il progetto supera o spende questo può essere lo sviluppatore e migliore amico dei tester.

Come risultato di tutto ciò, personalmente penso che sia una buona idea avere una specifica anche per progetti solisti e certamente per qualcosa di abbastanza complesso da richiedere test formali.

L'altra cosa che vorrei sottolineare, (in risposta a 太極 者 無極 而 生) è che se aspetti di formalizzare le specifiche e scrivi i test fino a che il codice non viene eseguito, allora la specifica potrebbe non essere mai eseguita, il test probabilmente non sarà mai fatto e qualsiasi problema trovato sarà possibilmente non vengono mai affrontati perché il budget e il periodo di tempo sono stati entrambi esauriti e ci sarà molta pressione per far uscire le cose. Parlo per esperienza come sono, non per la prima volta , dovendo riscrivere il codice di qualcun altro che è stato un incubo di manutenzione per anni perché:

  • La specifica originale non è mai stata rilasciata, non è mai stata aggiornata, è diventata completamente fuori dal sistema consegnato, (al punto in cui il sistema fisico soddisfa solo le specifiche per le dimensioni esterne ma in nessun altro aspetto.
  • Non sono mai stati sviluppati test formali per il software (dopotutto senza una specifica simile al sistema non c'era modo di scrivere test significativi).
  • Il budget era esaurito, quindi alcuni test "sembra funzionare" sono stati eseguiti test e i sistemi sono stati spediti in modo che il cliente potesse essere fatturato.
  • Il patching di un problema ha causato la visualizzazione di problemi vecchi o nuovi perché non erano disponibili test per verificare il corretto funzionamento del sistema.
risposta data 08.09.2017 - 09:07
fonte

Leggi altre domande sui tag