La costruzione del software è un processo complesso. Oltre a padroneggiare i vari strumenti e linguaggi di programmazione, c’è anche la comprensione dei vari ruoli dello sviluppo del software. Come molti di noi sanno, i grandi progetti non coinvolgono solo la codifica. I grandi progetti coinvolgono anche altre risorse per la raccolta dei requisiti, la prototipazione e il test.
Il processo di convalida del codice è spesso definito Quality Assurance. Tuttavia, la frase è in qualche modo fuorviante. Invece di assicurare la qualità del codice, il vero obiettivo è misurarla – spesso mentre il progetto si evolve. Conosciuto anche come test-driven development (es. TDD), questa sottile differenza può essere vista quando si esaminano i ruoli delle funzioni di qualità. Questi includono i seguenti:
Perché test UNIT?
Come mostrato, la misurazione della qualità è spesso raggruppata in attività automatizzate e manuali. Come qualcuno interessato agli algoritmi, il codice aggiuntivo noto come test delle unità funziona per testare il progetto software principale. I test unitari sono solitamente scritti dagli sviluppatori e sono il fulcro in un ambiente TDD. Per esempio, i test unitari sono essenziali nello sviluppo di questo libro. Usando il framework XCTest di iOS, rivediamo come funzionano i test unitari in Swift.
LAVORARE CON XCTEST
Se avete familiarizzato con i concetti di Swift rivisti nel libro, imparare a scrivere test unitari dovrebbe essere semplice. Come discusso, i test unitari funzionano per esercitare il codice che manca di un’interfaccia utente finale. Per illustrare, rivediamo i casi di test che esercitano una struttura dati Stack.
Mentre il libro non esamina i particolari dell’ambiente di sviluppo integrato (IDE) Xcode, va notato che i test possono essere eseguiti per funzione, classe o obiettivo. Usando Xcode, i test unitari sono stabiliti aggiungendo un nuovo Test Target al vostro progetto di codice principale. Una volta configurati, i test unitari possono essere eseguiti dall’IDE o dalla linea di comando.
REGOLE DEI TEST
Anche se non è obbligatorio, è considerato una buona pratica se il file dei test unitari corrisponde strettamente alla convenzione di denominazione dei nostri file di implementazione. Nel nostro caso, useremo StackTest.swift. Per ottenere l’accesso ai metodi e alle proprietà primarie di Stack dal nostro progetto principale, il file includerà anche una dichiarazione di importazione testabile:
Come altri framework di test unitari, XCTest funziona integrando le caratteristiche del linguaggio Swift con funzioni specifiche relative ai test. I metodi essenziali sono raggruppati come asserzioni. Quando si creano i test, il compilatore riconoscerà i test unitari con le funzioni precedute dalla parola chiave test.
A differenza delle normali funzioni Swift, i test unitari sono intenzionalmente progettati come unità logiche indipendenti. Come risultato, i metodi di test non accettano argomenti e non restituiscono valori. In alternativa, i dati di test possono essere gestiti attraverso metodi helper e sequenze di inizializzazione/rimozione. Considerate quanto segue:
PIANIFICAZIONE DEI TEST
Come discusso, l’operazione principale di una struttura dati Stack è l’aggiunta e la rimozione di elementi. Invece di scrivere una singola funzione per testare tutte le operazioni, il nostro piano di test isola ogni operazione principale dello Stack con un proprio test. Come visto con testPushStack, l’asserzione XCTAssertTrue controlla la corretta inizializzazione della variabile Stack.count. Il passo successivo consiste nell’esercitare Stack.push iterando attraverso l’array di elementi numberList. Per verificare che ogni test utilizzi gli stessi dati, numberList viene popolato usando il metodo di configurazione della classe XCTestCase.
Con il test unitario per aggiungere elementi dello Stack implementato, possiamo scrivere il prossimo test per rimuovere elementi: