Test dell'unità XCode

Question

Non ho mai usato il Test unità e ne comprendo gli usi, ma non so quando e come usarlo.

Vorrei sapere quando valga la pena utilizzare Test unità, magari con alcuni esempi.

Answer 1

Si dovrebbe quasi sempre il test dell'unità e si dovrebbe scrivere il codice con le unità test in mente. Gli estremisti scrivono i test anche prima di scrivere il codice (si chiama TDD - Test Driven Development).

Ti darò un esempio di vita reale: recentemente ho dovuto codificare un NSArray ordinato che supporta "intervalli". Significato, la matrice dovrebbe sapere come inserire un intervallo e tenerlo ordinato.

Ad esempio, la matrice sarà simile a questa: [1-3, 5-9, 12-50]. In questo esempio ci sono 3 intervalli nella matrice e, come puoi vedere, sono ordinati. Dopo aver scritto la mia classe (l'ho chiamata IntervalsArray), I HAD scrivere test per verificare che funzioni correttamente e che non lo "interromperò" se io o qualcun altro apportare modifiche al codice in futuro.

Ecco alcuni test di esempio (pseudo-codice):

Test 1:

- Create a new IntervalsArray 
- Insert a new interval to the array 
- (TEST) make sure the array has 1 object in it 

Test 2:

- Create a new IntervalsArray 
- Insert 2 intervals into the array: [1-3] and [5-9] 
- (TEST) make sure there are 2 items in the array 
- (TEST) make sure interval [1-3] comes before interval [5-9] 

Alla fine ho avuto qualcosa come 15 test a copertura ogni aspetto del mio nuovo array.

Ecco uno good unit-testing with Xcode tutorial.

È anche possibile scrivere test di logica (che sono più complicati dei test di unità) per testare l'interfaccia utente. Leggi un po 'su UIAutomation, che è il modo di testare l'interfaccia utente di Apple. Non è perfetto, ma è abbastanza buono. Here's an excellent tutorial su questo.

Se ti consideri un buon programmatore, dovresti scrivere unit test per il tuo codice.

Answer 2

Ogni volta che scrivi un'applicazione con classi, che non sono le tue. È un buon momento per aggiungere test unitari, per testare quelle classi.

Tutti tranne le app di base avranno le proprie classi, quindi è quasi sempre una buona idea di unit test.

Se si stanno creando librerie che verranno utilizzate da altri programmatori o che verranno utilizzate in più progetti, queste dovrebbero sempre essere sottoposte a test unitari.

I test di unità consentono di risparmiare molto tempo quando le cose cambiano, ad esempio, una nuova versione del sistema operativo viene fuori, è molto meglio testare con i test delle unità, quindi semplicemente testare l'app.

Answer 3

Scrive unit test ogni volta che si scrive codice che si dovrà mantenere. Cioè, se mai si vuole refactoring qualcosa - cambiare il codice, ma mantenendo il comportamento. Che è praticamente ogni bit del codice di produzione.

Il controesempio di "Hello, World" non deve preoccuparsi del codice che si intende eliminare. Una "soluzione spike" è solo per capire come si potrebbe affrontare un problema. Una volta capito, buttalo via e ricomincia. Solo questa volta, inizi con i test.

Chiamare TDD "estremista" lo rende irrazionale e poco pratico. Infatti, una volta che impari TDD, risparmia tempo/denaro.

Vedere Unit Testing Example with OCUnit per un esempio di come funziona TDD.

Answer 4

Le altre risposte dicono quando ma non proprio come, quindi permettimi di aggiungere anche una risposta.

Quando

Ogni volta che si sta scrivendo codice di produzione che si sta andando a tenere, si dovrebbe avere Unit Testing per esso. La formazione più utili che ho visto su questo è stato il seguente 2-parte serie di video:

• Understanding Test Driven Development (parte 1)
• Unit Testing Best Practices with Roy Osherove (parte 2)

I primi cinque minuti o giù di lì sono solo intro quindi puoi saltare alla fine di quello.

Come

Sto utilizzando Xcode 7 con Swift.

Avviare un nuovo progetto e aggiungere un test unitario.

Sto chiamando il mio MyProject. Se apri il gruppo MyProjectTests in Project Navigator, vedrai che Xcode ha già creato un file di test unitario chiamato MyProjectTest.swift.

è possibile eliminare tutti i metodi di esempio per ora e aggiungere un nuovo func per testare il proprio metodo di classe. Assicurati di aggiungere la riga @testable import MyProject in alto. Se il nome del tuo progetto contiene spazi, allora sostituisci gli spazi con caratteri di sottolineatura. (Ad esempio, "Il mio progetto di esempio" utilizza @testable import My_Example_Project.)

Sto seguendo lo schema di denominazione testMethodNameBeingTested_Senario_ExpectedBehavior. I nomi delle unit test devono iniziare con "test".

farò fare qualcosa di simile:

import XCTest 
@testable import MyProject 

class MyProjectTests: XCTestCase { 

    func testSum_TwoNumbers_ReturnsSum() { 
     // Arrange (set up the needed objects) 
     let myClass = MyClass() 

     // Act (run the method you want to test) 
     let sum = myClass.sum(1, 2) 

     // Assert (test that the behavior is as expected) 
     XCTAssertEqual(sum, 3) 

    } 
} 

Naturalmente, la build fallisce perché non abbiamo ancora aggiunto la classe MyClass.

Aggiungi classe.

Sto aggiungendo un file Swift a MyProject chiamato MyClass.

class MyClass { 

    func sum(a: Int, _ b: Int) -> Int { 
     return a + b 
    } 
} 

Se dovessi seguire davvero i principi TDD, aggiungerei solo il nome della funzione, non restituire il valore corretto. Ma per brevità farò solo l'intero metodo ora.

Premere il pulsante di test accanto alla classe dell'unità di prova o il metodo per eseguire nuovamente il test e deve passare.

Per vederlo fallire (una parte importante di Unit Testing) è possibile fare qualcosa come return 0 nel metodo sum di MyClass. Poi si dovrebbe vedere la seguente quando si esegue prova:

È possibile tornare indietro e correggere questo e poi aggiungere ulteriori unit test. Puoi anche creare altri file di unit test per classi diverse, se lo desideri. Basta fare clic con il pulsante destro sul gruppo MyProjectTest nel Navigatore progetto e scegliere "Nuovo file", quindi scegliere Test Case Class.

correlati

Xcode UI Test example