L’idea sarebbe andare a catturare i bug più in fretta possibile e andare ad automatizzare le operazioni di collaudo. Non è la stessa cosa ovviamente se me ne accorgo prima o dopo. Esiste un costo della permanenza di bug e sarebbe bene andarli a beccare in fase di implementazione.

Non posso avere mai la garanzia di aver programma che sia senza problemi. Anche se fossimo bravissimi a fare una suite di test dettagliatissima. Il testing serve essenzialmente per fare solamente una barriera più alta per l’attaccante.

Tecniche che andremo a considerare

• unit testing
• analisi statica (programma NON in esecuzione)
• analisi dinamica (programma IN esecuzione)

Tipologie di test

• Functional test
• Integration test: verifico le interazioni più comuni che l’utente ha col software. Vedo i requisiti di funzionamento del programma in generale.
• Regression test: se faccio varie modifiche o introduco errori (funzionali, performance, sicurezza), sto portando il programma a comportarsi peggio di prima in termini di performance o di sicurezza, o anche funzionale.
• Performance: praticamente faccio uno stress test del programma e verifico la stabilità del programma
• Security Test: questi test hanno l’obiettivo di beccare debolezza nei moduli software. Possono essere condotti staticamente o dinamicamente. Si lavora per esempio su una copia del programma, ovviamente non in produzione.

Ci serve fare testing per andare a individuare bug, difetti debolezze, crash o output strani. Cerco di andare a catturare tutte questi aspetti. Ogni test che faccio è una domanda che essenzialmente faccio alla mia architettura.

Quando scriviamo i test ci viene da ragionare rispetto al funzionamento generale del sistema e il design. La soluzione finale sarebbe prima fare il test e poi il programma → test driven development. Non dobbiamo andare a fare dei test che siano fatti alla fine del tutto e che quindi diventano una opportunità per trovare degli escamotage. Dobbiamo partire già dai test che vogliamo andare a superare. Rischiamo in caso contrario di andare a scrivere dei pessimi test. Nel mondo ideale per non avere bias chi scrive test ≠ developer. In un mondo però super ideale parto da ogni fail di test che ho creato inizialmente senza aver creato il programma e inizio a scrivere moduli di codice per ogni test. Vado avanti in maniera modulare e incrementale praticamente.

L’idea sarebbe andare ad essere uno che prima testa tanto e poi scrive il codice.

Se il test è fatto bene possiamo andare a fare refactoring in maniera migliore. Alla fine riesco ad essere anche molto più modulare.