Aumentare la testabilità, quando si codifica con Bold per il framework Delphi

Question

Sfondo Lavoro in un team di 7 sviluppatori e 2 tester che lavorano su un sistema logistico. Utilizziamo Delphi 2007 e lo sviluppo modeldriven con Bold for Delphi come framework. Il sistema è in produzione da circa 7 anni e ha circa 1,7 milioni di linee di codice. Rilasciamo in produzione dopo 4-5 settimane e dopo quasi tutte le versioni dobbiamo fare alcune patch per bug che non abbiamo trovato. Questo è ovviamente irritante per noi e per i clienti.

Test corrente La soluzione è ovviamente più test automatico. Attualmente abbiamo test manuali. Un TestDbgenerator che inizia con un database vuoto e aggiunge dati dai metodi modellati. Abbiamo anche Testcomplete che esegue alcuni script di base per testare la GUI. La mancanza di tempo ci impedisce di aggiungere altri test, ma gli script sono anche sensibili ai cambiamenti nell'applicazione. Per alcuni anni ho davvero provato i test unitari con DUnit, ma ho rinunciato dopo alcuni giorni. Le unità hanno connessioni troppo forti.

precondizioni test delle unità credo di sapere alcune precondizioni per il test delle unità:

• Scrivi piccoli metodi che fanno una cosa, ma farlo bene.
• Non ripeterti.
• Prima scrivere il test che non riesce, quindi scrivere il codice in modo che il test passi.
• Le connessioni tra le unità devono essere libere. Non dovrebbero sapere molto l'uno dell'altro.
• Utilizzare l'iniezione dipendente.

Framework da utilizzare possiamo effettuare l'aggiornamento a Delphi XE2, soprattutto a causa del compilatore a 64 bit. Ho guardato un po 'lo Spring ma questo richiede un aggiornamento da D2007 e questo non succederà ora. Forse l'anno prossimo.

La domanda La maggior parte del codice non viene ancora testata automaticamente. Quindi qual è il percorso migliore per aumentare la testabilità del vecchio codice? O forse è meglio iniziare a scrivere test solo per nuovi metodi? Non sono sicuro di quale sia il modo migliore per aumentare i test automatici e i commenti su di esso sono i benvenuti. Possiamo usare D2007 + DUnit ora e poi passare facilmente a Delphi XE2 + Spring in seguito?

EDIT: sulla metodologia corrente di prova per il test manuale è solo "libra su di esso e cercare di romperlo", come lo chiamano Chris.

Answer 1

Vuoi il libro di Michael Feathers, Working Effectively with Legacy Code. Mostra come introdurre test (unitari) per codice che non sono stati scritti pensando alla testabilità.

Alcuni dei capitoli sono chiamati per scuse uno sviluppatore potrebbe dare del motivo per cui il test vecchio codice è dura, e contengono studi di casi e ha suggerito modi per risolvere ogni problema:

• non ho molto tempo e devo cambiarlo
• non posso correre questo metodo in un test harness
• questa classe è troppo grande e non voglio che per ottenere qualsiasi grande
• ho bisogno di cambiare un metodo mostro e Non posso scrivere test per questo.

Comprende anche molte tecniche per rompere le dipendenze; alcuni potrebbero essere nuovi per te e alcuni potrebbero già saperlo ma non hanno ancora pensato di usarli.

Answer 2

La tua squadra di test è troppo piccola, IMO. Ho lavorato in team in cui il reparto QA supera gli sviluppatori. Prendi in considerazione di lavorare su "sprint" di blocchi gestibili (funzionalità, correzioni) che si adattano a cicli più piccoli. "Agile" incoraggerebbe sprint di 2 settimane, ma potrebbe essere troppo stretto. In ogni caso, manterrebbe il QA costantemente occupato, lavorando più avanti rispetto alla finestra di rilascio. In questo momento, sospetto che siano inattivi finché non gli dai una quantità enorme di codice, quindi sono sommersi. Con cicli di rilascio più brevi, puoi tenere impegnati più tester.

Inoltre, non hai parlato molto della loro metodologia di test.Hanno degli script standard che eseguono, in cui verificano l'aspetto e il comportamento rispetto all'aspetto e al comportamento previsti? O si limitano a "calpestarlo e cercare di romperlo"?

IMO, il test Dunit è difficile da fare con molte dipendenze come database, comunicazioni, ecc. Ma è fattibile. Ho creato le classi DUnit che eseguono automaticamente gli script di installazione del database (cerca un file .sql con lo stesso nome della classe sottoposta a test, esegui lo sql, quindi procede con il test) ed è stato molto efficace. Per le comunicazioni SOAP, ho un SOAPUI mockservice in esecuzione che restituisce risultati in scatola, quindi posso testare le mie comunicazioni.
Ci vuole lavoro, ma ne vale la pena.

Answer 3

I requisiti per unità di test automatizzati sono esattamente questo:

1. utilizzare un test delle unità (per esempio, dunit).
2. utilizzare una sorta di quadro di derisione.

L'elemento 2 è il difficile.

ASCIUTTO, piccoli metodi, iniziare con un test e DI sono tutti zucchero. Per prima cosa devi avviare il test dell'unità. Aggiungi DRY, ecc. Mentre vai avanti. L'accoppiamento ridotto aiuta a rendere più facilmente le unità testate, ma senza un gigantesco sforzo di refactoring, non ridurrete mai l'accoppiamento nella vostra base di codice esistente.

Considera di scrivere test per cose nuove e cose che sono state modificate nella versione. Nel tempo otterrai una base ragionevole di test unitari. Le novità e i cambiamenti possono essere anche rifattorizzati (o scritti bene).

Inoltre, si consideri un processo di compilazione automatizzato che esegue test unitari e invia e-mail quando si interrompe la costruzione.

Questo copre solo le prove dell'unità. Per i tester del QA, avrai bisogno di uno strumento (esistono, ma non ne posso pensare nessuno) che permetta loro di eseguire test automatici (che non sono test unitari).