Dividi i test per metodo o comportamento? [duplicare]

Question

Dividi i test per metodo o comportamento? [duplicare]

#1 da (5 voti)
#2 da (3 voti)
#3 da (0 voti)

2

Ho un metodo che ho bisogno di testare che ha più casi che devono essere testati, e ogni caso richiede alcune righe di codice da testare. In poco tempo la funzione di test è lunga 50 righe ed è un po 'difficile trovare i guasti. (No, questa funzione non è in grado di essere ragionevolmente suddivisa in metodi ragionevolmente piccoli e facilmente testabili.)

I metodi di test sono concepiti per essere specifici per un metodo e nessun altro test copre quel metodo, o è corretto avere più metodi di test che coprono aspetti diversi di una funzione? Esempio:

@Test
public void testSomeComplexMethod() {
    // lots of code
}

// or

@Test
public void testSomeComplexMethodAspect1() {
    // a little code that just tests aspect 1
}

@Test
public void testSomeComplexMethodAspect2() {
    // a little code that just tests aspect 2
}

unit-testing xunit

posta J Atkin 10.02.2017 - 02:23

fonte

3 risposte

3

Il bello dei test unitari è che saprai esattamente cosa c'è che non va se un dato test fallisce.

Non hai questa funzione nei livelli più alti di test, hanno altri scopi.

Ogni test di unità dovrebbe avere una una e una sola ragione per fallire (negli stessi casi, potrebbe essere necessario più di un assert per verificare questo motivo). Se è possibile modificare la funzione target in più punti e rendere lo stesso test non riuscito, provare a dividere il test. Questo è lo scopo del test delle mutazioni .

OBS:

Se il framework di testing dell'unità presenta caratteristiche come @covers annotazioni di PHPUnit , dovresti utilizzarlo per assicurarti di coprire esattamente il caso che ti aspetti da un test.

risposta data 10.02.2017 - 11:36

fonte

0

Un altro vantaggio derivante dall'avere più test è che è possibile scomporre le funzionalità comuni in quelle che vengono chiamate funzioni di utilità.

Di solito, dopo alcuni test, troverete che tutti stanno facendo lo stesso tipo di configurazione e impostando le stesse proprietà per le condizioni. Ma i valori per le condizioni stanno per variare.

Il risultato è che quando estrai i punti in comune, finisci per passare le diverse condizioni alle tue funzioni di utilità per gestire la configurazione.

Questo ha due effetti.

Uno, risponde alla vecchia domanda su come si prova il codice di test. Le funzioni di utilità vengono riutilizzate, quindi testate automaticamente. Se tutti i test falliscono, il problema è probabilmente nella funzione o nella configurazione del SUT. Se solo uno fallisce, è nel test stesso o nel comportamento che stai provando a testare.

Due, con meno rumore il tuo codice è più pulito, l'intento è più evidente, i test sono più facili da leggere e mantenere.

Qualsiasi configurazione tu voglia fare non varia il test da testare, e quindi non ha bisogno di parametri, va nella routine [Setup].

Infine, interrompo gruppi di test in classi separate quando hanno bisogno di un [Setup] separato sulla teoria che stai testando qualcosa di separato.

risposta data 10.02.2017 - 17:02

fonte

Leggi altre domande sui tag unit-testing xunit

Posso mantenere il copyright del nome / logo di un'applicazione per il copyleft (GPL) altrimenti? Scrum ha modi specifici per testare il software?

score 5 · Accepted Answer

È del tutto normale disporre di diversi metodi di test per testare i comportamenti di un singolo metodo nel SUT . In effetti, vi incoraggio vivamente a farlo, a meno che la funzionalità non possa essere testata usando un qualche tipo di test guidato dai dati (si veda ad esempio NUnit's Attributo TestCase ).

Esempio simile al tuo, usando solo una convenzione di denominazione diversa:

@Test
public void someComplexMethod_BehavesLikeThis_WhenTheseConditionsApply() {
    // a little code that just tests behavior 'like this' given 'these conditions'
}

Inizio di una tangente:

(No, this function is not able to be reasonably split into reasonably small and easily testable methods.)

Ho difficoltà a credere che questo sia effettivamente vero. La funzione stessa potrebbe essere difficile da suddividere, ma il codice sottostante può essere quasi sempre estratto in entità separate che possono essere più facilmente testate in isolamento - cambiando la funzione originale in un "orchestratore" che utilizza le nuove parti.