Come si scrive un test unitario per verificare che una funzione elabori il suo risultato?

Question

Ho un'origine dati da cui posso richiedere un elenco di persone che vivono in un paese (qualsiasi) e un metodo che recupera le persone da tale origine dati e le ordina in base al loro nome in ordine alfabetico. Come dovrei scrivere il mio test unitario per assicurarmi che la parte di ordinamento del mio metodo funzioni correttamente?

Questo è ciò che il mio SUT assomiglia:

class PeopleStuff { 

    public IData data; 

    public List<Person> getSortedPeopleForCountry(String countryName) { 
     List<Person> people = data.getPeopleForCountry(countryName); 

     Comparator nameComparator = new PersonNameComparator(); 
     Collections.sort(people, nameComparator); 

     return people; 
    } 

} 

E questo è ciò che il mio test di unità si presenta come:

@Test public void testGetPeopleSortsByPeopleName() { 
    String COUNTRY = "Whatistan"; 

    // set up test (the 3 lines below are actually in a @Before setup method) 
    PeopleStuff peopleStuff = new PeopleStuff(); 
    IData mockData = createNiceMock(IData.class); 
    peopleStuff.data = mockData; 

    // set up data 
    List<PersonName> mockPeopleList = new ArrayList<PersonName>(); 
    mockPeopleList.add(new Person(COUNTRY, "A")); 
    mockPeopleList.add(new Person(COUNTRY, "D")); 
    mockPeopleList.add(new Person(COUNTRY, "B")); 
    mockPeopleList.add(new Person(COUNTRY, "C")); 

    when(mockData.getPeopleForCountry(COUNTRY)).thenReturn(mockPeopleList); 

    // exercise 
    List<String> result = peopleStuff.getSortedPeopleForCountry(COUNTRY); 

    // assert 
    assertEquals("A", result.get(0).name); 
    assertEquals("B", result.get(1).name); 
    assertEquals("C", result.get(2).name); 
    assertEquals("D", result.get(3).name); 
} 

Che cosa ho bisogno di sapere è se il modo in cui mi sto spegnendo i dati , eseguendo il test e rendendo le asserzioni corrette, o se ci sono modi migliori per farlo.

La mia applicazione ha molti metodi per testare e molti algoritmi di ordinamento personalizzati; Ho implementato tutti i test per utilizzare 4 valori che ho mozzato così, in a "random" order che scelgo quando scrivo il test.

---

Devo testare solo se vengono chiamati i comparatori? Non mi sembra giusto, perché non so se vengono chiamati i dati giusti o al momento giusto nell'algoritmo che si trova all'interno di getSortedPeopleForCountry(). Voglio rilevare situazioni come questa:

public List<Person> getSortedPeopleForCountry(String countryName) { 
    List<Person> people = data.getPeopleForCountry(countryName); 

    Comparator nameComparator = new PersonNameComparator(); 
    List<Person> sortedPeople = new ArrayList<Person>(people) 
    Collections.sort(sortedPeople, nameComparator); 

    return people; // oops! 
} 

Devo lasciare in questo modo e aggiungere comparatori finte che utilizzano i veri comparatori ma anche verificano che stanno chiamati?

Sto facendo bene?

Answer 1

Penso che il tuo test corrente sia molto buono - i test sono realistici, esercitano tutto il codice e stai prendendo in giro l'origine dati & utilizzando l'iniezione di dipendenza per fornire un'origine dati fittizia. C'è un sacco di buone pratiche in corso in questo test.

Sulla questione se si dovrebbe cercare di prendere in giro i comparatori (e quindi rendere il test su testGetPeopleSortsByPeopleName un test di unità pura), sarà sicuramente ottenere due opinioni diverse qui:

• un purista sosterrebbe che il test è tecnicamente un test di integrazione e, per avere i test di unità adeguati, è necessario regolare il test per utilizzare un comparatore di simulazione e quindi testare separatamente il comparatore.
• Un pragmatico sosterrebbe che il test è già di alta qualità e che non importa che non sia un test unitario nel senso più stretto. Inoltre, dividere questo in due test di unità separati può rendere il test meno leggibile - cosa che immagino sarebbe il caso del test di cui sopra se si trattasse di comparare simulatori.

La mia opinione personale è che si dovrebbe lasciare così com'è, il fatto che si dispone di una elevata qualità, prova leggibile che esercita tutto il codice e afferma in modo efficace le vostre esigenze è molto più importante di preoccuparsi di avere rigorosamente pura test unitari.

L'unico modo in cui il test sembra aver bisogno di miglioramenti è la lunghezza del metodo di test: penso che un piccolo metodo di estrazione potrebbe aiutare a migliorare la leggibilità e rendere il metodo di test più espressivo. Vorrei puntare a qualcosa di simile:

@Test public void testGetPeopleSortsByPeopleName() { 

    peopleStuff.data = buildMockDataSource(COUNTRY, "A", "D", "B", "C") 

    List<String> result = peopleStuff.getSortedPeopleForCountry(COUNTRY); 

    assertPersonList(result, "A", "B", "C", "D") 
} 

private IData buildMockDataSource(String country, String ... names) { 
    ... 
} 

private void assertPersonList(List<Person> people, String ... names) { 
    ... 
} 

Answer 2

Separare la logica di ordinamento dalla restituzione dell'elenco. Quindi avrei getPeopleForCountry (String countryName) restituire solo una lista mentre una lista ordinata sarebbe stata restituita da getSortedPeopleForCountry (List). In questo modo puoi testare come funziona prima e dopo l'ordinamento. Inoltre, potresti voler sovrascrivere il metodo Equals() per confrontare i nomi se è quello con cui vuoi andare, ma in seguito vorrai confrontarti con altre proprietà. Questa è la tua chiamata.

Answer 3

ObjectA[] arr = objectAList.toArray(new ObjectA[objectAList.size()]); 
for (int i = 0; i < objectAList.size() - 1; i++) { 
     int j = i + 1; 
     assertTrue(arr[i].getDate().compareTo(arr[j].getDate()) >= 0); 
} 

Questo Codice rappresenta un esempio in cui gli oggetti è ordinato per data campo in ordine decrescente ArrayList contaning Objecta. Stiamo verificando se il membro della lista ha una data inferiore o uguale rispetto al suo predecessore.