Come fare a Test Driven Development in modo corretto?

Question

Ho letto di TDD e l'ho provato sul mio nuovo progetto.

Capisco che in TDD è come test blackbox, vale a dire che conta quello piuttosto che come .Quindi, ho concluso e si fermò metodi di prova privati ​​dopo aver letto su molti post come non è il modo corretto.

Tuttavia, non sono riuscito a farlo a causa di questi motivi.

Vi mostrerò l'esempio: Ho un programma che legge un paragrafo di testo, quindi ho scritto qualcosa di simile nel mio metodo di test (per tdd step1).

/* 
My program reads a textual paragraph from file and saves it to my custom paragraph object; 
*/ 

Quindi di conseguenza ho fatto questo metodo per creare il RED caso .

public void paragraphMustNotBeNullTest(){ 
File f = new File("some path") 
ParagraphReader reader= new ParagraphReader(); 
reader.read(); 
assertNotNull("my custom paragraph is null",reader.getCustomParagraph()); 
} 

ho scritto seguente codice:

package com.olabs.reader; 

import java.io.FileInputStream; 
import java.io.InputStream; 

import com.olabs.models.OlabsParagraph; 

public class Para { 


    private String paragraphText = null; 
    private Paragraph oParagraph = null; 

    public Paragraph getCustomParagraph() { 
     return oParagraph; 
    } 
    public void setoParagraph(Paragraph oParagraph) { 
     this.oParagraph = oParagraph; 
    } 

    public void read() { 
     InputStream is = new FileInputStream("abc......"); 
//  .. 
     String text = is.read(); // assume I got text read from file. 
     this.paragraphText = text; 
    } 


    private void createCustomParagraph() 
    { 
     Paragraph p = new Paragraph(); 
     p.setText(paragraphText); 
     p.setId(1); 
     p.setType("Story"); 
     ........... 
    } 

    private void countWords() 
    { 
     // counting words in paragraph logic 
    } 


} 

Ora il problema è che io so in anticipo che userò countingwords e createCustomParagraph come metodi privati.

Così, in questo caso devo andare con:

1. crearli come pubblico e seguire il ciclo TDD.

2. renderli privati.

3. eliminare i test per loro (poiché i metodi sono ora privati ​​e inaccessibili per i test). Penso che questo sia un modo piuttosto ingombrante e scorretto per fare tdd.

Sono confuso su this.Everyone dice scrivere il codice solo dopo che si scrive un test in mancanza, ma qui se so che sto per scrivere un metodo privatoallora come farò a fare questo?

Vi chiedo di correggermi se sbaglio da qualche parte. Anche se possibile, dare qualche esempio reale ...

Inoltre, temo che la maggior parte del tempo mi sarà test di editing o la rimozione a causa di problemi di accesso prescrittori o refactoring ...

Nota: Questa è non una domanda doppia. Non ho una buona risposta per le situazioni in tempo reale. In tutti gli esempi che ho visto, mostrano solo una singola classe con specificatori di accesso pubblico o predefiniti, quindi in realtà non mostrano esattamente come lavorare nel progetto in tempo reale.

Answer 1

Dalla mia esperienza personale, si sta testando la classe e l'interfaccia per la classe dal resto dell'applicazione. I casi di test TDD devono essere scritti rispetto ai metodi pubblici della classe.Il punto è testare che quando stimolato, la classe emette i risultati desiderati per superare i criteri del test. I metodi privati ​​interni verranno testati come parte dei test dell'interfaccia pubblica, ma l'obiettivo è verificare che l'interfaccia accessibile al pubblico funzioni. Dici di sapere in anticipo che i metodi privati ​​saranno utilizzati, ma se qualcuno si rifiuta di capire come sono fatte le cose nella classe senza cambiare il comportamento esterno, sarai comunque in grado di usare i tuoi test esistenti e verificare che il refactoring non abbia rotto un metodo precedentemente funzionante.

Answer 2

Se un metodo è un dettaglio di implementazione della cosa principale che si sta costruendo e che dovrebbe rimanere privato, ciò non significa che non ci sia modo di scrivere un test per questo. Puoi rendere questa funzionalità parte di un'altra classe in cui può essere pubblica, scrivere test che la esercitino direttamente, quindi chiamarla privatamente dalla cosa principale. In questo modo è possibile testare i metodi privati, nessun test viene eliminato e non è necessario passare attraverso le contorsioni per testare qualcosa indirettamente quando la cosa che lo utilizza non può esporre l'accesso a tutto ciò che si desidera testare. E ora invece di avere metodi privati ​​che sono pezzi nascosti di codice gnarly, hai blocchi di costruzione ben testati pronti per il riutilizzo da qualche altra parte.

Answer 3

Ottima domanda. L'ho anche chiesto molte volte. E in generale le risposte dicono che devi pensare ai test unitari che precedono un'implementazione delle funzionalità principali come i telai . Questi frame definiscono rigorosamente la funzionalità.

Quindi potresti anche non conoscere i metodi privati ​​prima di implementare alcune classi particolari. Ma dal momento che hai una serie di prove RED, l'unica cosa che devi fare è renderle verdi. Non importa come lo farai (metodi pubblici o privati).

Un obiettivo numero uno è scrivere le righe minime di codice, che devono essere coperte da dal test di unità. Ho coperto più approfonditamente il TDD topic sul mio blog.