Non credo che i test unitari necessariamente testino i requisiti: 1) i test unitari operano contro componenti di livello molto basso (metodi / classi / interfacce / eccetera) testati come unità stand-alone; 2) i requisiti devono essere testati mentre il tecnico di prova progetta i test di integrazione / sistema durante la fase di progettazione dei requisiti; 3) funzionalità, requisiti e specifiche sono testati (di nuovo) una volta che il sistema si trova in uno stato operativo; e 4) utilizzando un approccio di sviluppo software iterativo, vengono rivisitate molte fasi del ciclo di vita dello sviluppo per rafforzare i requisiti, la progettazione e lo sviluppo - i processi che si verificano nuovamente.
Perché il test dell'unità non è appropriato per i requisiti di test . I test unitari non necessariamente rivelano un problema di requisiti per una serie di motivi. Uno, se un requisito è stato scarsamente comunicato, è probabile che il requisito sia stato incorporato nella progettazione del software e nello sviluppo successivo; di conseguenza, se il test dell'unità segue l'esempio, seguendo correttamente un requisito errato, il test dell'unità non presenterà nulla. Due, se il requisito è stato adeguatamente documentato e il team di sviluppo ha erroneamente interpretato il requisito, in modo simile al punto 1, la mancata interpretazione verrà sottoposta al test dell'unità. Tre, per quanto riguarda la mia esperienza, il test unitario è svolto dallo sviluppatore e fa parte del ciclo di vita dello sviluppo: il test dell'unità è di basso livello e probabilmente non rappresenterà un requisito, a meno che ogni requisito completo non sia rappresentato dal suo stesso metodo, che è molto, molto improbabile.
Esempio . Considerare i test unitari in termini di metodi. Il test unitario verifica in gran parte che, date le pre-conduzioni, le post-condizioni rimangono valide dopo l'esecuzione del metodo sotto test. Lo scopo del testing unitario è testare / verificare i metodi, eccetera, di un sistema software, partendo dai metodi più atomici o primitivi, progredendo verso quelli più complessi. Testando ogni metodo di basso livello, si verifica se funziona, una cosa senza senso. A questo punto, lo sviluppatore non ha bisogno di ripetere il test del metodo di basso livello come unità indipendente. Mentre si spostano verso l'alto in complessità verso metodi di livello superiore, il test unitario verifica questi metodi, dimostrando che i metodi primitivi, da cui sono composti i livelli superiori, lavorano insieme. Per quanto ne so, questo è più o meno il punto in cui i test unitari si fermano.
Come vengono testati i requisiti . In un progetto ben pianificato, il test engineer (un tester integrato / di sistema) inizia a progettare i test mentre vengono scritti i requisiti. Attraverso questa attività, i requisiti vengono verificati, prima della progettazione del sistema, e molto prima che venga scritto un punto di codice. Una volta che il sistema diventa disponibile in una forma utilizzabile, i requisiti vengono verificati tramite test funzionale / di integrazione / di sistema.