Wie man Test Driven Development richtig macht?

Question

Ich habe über TDD gelesen und ich habe es an meinem neuen Projekt versucht.

Ich verstehe, dass in TDD es wie Black-Box-Test ist, dh es zählt WHAT statt wie .So, ich abgeschlossen und beendet die Prüfung private Methoden nach an vielen Stellen darüber zu lesen, wie Es ist nicht richtig.

Allerdings habe ich es aus diesen Gründen nicht geschafft.

Ich werde Ihnen durch ein Beispiel zeigen: Ich habe ein Programm, das einen Textabsatz liest, also schrieb ich etwas in meiner Testmethode (für tdd step1).

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

So dementsprechend habe ich diese Methode, um den RED Fall zu erstellen.

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

Ich habe folgenden Code geschrieben:

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 
    } 


} 

Nun das Problem ist, ich weiß vorher, dass ich countingwords und createCustomParagraph als private Methoden verwenden.

So, dass Fälle sollte ich gehen mit:

1. sie als öffentliche Schaffung und TDD-Zyklus folgen.

2. machen sie privat.

3. löschen Sie die Tests für sie (da die Methoden jetzt privat und für Tests nicht zugänglich sind). Ich denke, das ist ziemlich umständlich und falsche Art, tdd zu tun.

Ich bin verwirrt über this.Everyone sagt Code schreiben, erst nachdem Sie einen fehlerhaften Test schreiben, aber hier, wenn ich weiß, ich werde eine private Methode schreiben dann wie soll ich das tun?

Ich bitte Sie, mich zu korrigieren, wenn ich irgendwo falsch liege. Auch wenn möglich, etwas reales Beispiel geben ...

auch, fürchte ich, dass die meisten der Zeit, die ich Bearbeitung Tests sein wird oder sie aufgrund Zugriffsbezeichner Probleme oder Refactoring Entfernen ...

Hinweis: Diese ist nicht eine doppelte Frage. Ich habe keine gute Antwort für Echtzeit-Situationen. In allen Beispielen, die ich gesehen habe, zeigen sie nur eine einzige Klasse mit Standard-oder Public-Access-Spezifizierer, so zeigen sie wirklich nicht, wie genau in Echtzeit-Projekt arbeiten.

Answer 1

Aus meiner persönlichen Erfahrung testen Sie die Klasse und die Schnittstelle zur Klasse durch den Rest Ihrer Anwendung. Ihre TDD Testfälle sollten gegen die öffentlichen Methoden Ihrer Klasse geschrieben werden.Der Punkt besteht darin, zu testen, ob die Klasse bei der Stimulierung die gewünschten Ergebnisse ausgibt, um Ihre Testkriterien zu bestehen. Interne private Methoden werden als Teil der öffentlichen Schnittstellentests getestet, aber das Ziel besteht darin, zu verifizieren, dass die öffentlich zugängliche Schnittstelle funktioniert. Sie sagen, dass Sie im Voraus wissen, dass die privaten Methoden verwendet werden, aber wenn jemand das Verhalten in der Klasse ändert, ohne das äußere Verhalten zu ändern, können Sie trotzdem Ihre vorhandenen Tests verwenden und sicherstellen, dass das Refactoring nicht unterbrochen wurde zuvor funktionierende Methode.

Answer 2

Wenn eine Methode ein Implementierungsdetail der primären Sache ist, die Sie bauen, die privat bleiben sollte, bedeutet das nicht, dass es keine Möglichkeit gibt, einen Test dafür zu schreiben. Sie können diese Funktionalität in eine andere Klasse einfügen, in der sie öffentlich sein kann, indem Sie Tests schreiben, die sie direkt ausführen, und diese dann privat von der Hauptsache aus aufrufen. Auf diese Weise können Sie die privaten Methoden testen, keine Tests werden gelöscht, und Sie müssen nicht durch Verzerrungen etwas indirekt testen, wenn das Ding, das es verwendet, den Zugriff auf alles, was Sie testen möchten, nicht freilegt. Und jetzt, statt private Methoden zu haben, die verborgene Bits von gnarly Code sind, haben Sie gut getestete Bausteine ​​bereit für die Wiederverwendung woanders.

Answer 3

Sehr gute Frage. Ich habe es auch oft gefragt. Und im Allgemeinen sagten die Antworten, dass Sie an Komponententests denken müssen, die vor einer Implementierung der Hauptfunktionalität wie ungefähr Rahmen gehen. Diese Frames definieren genau die Funktionalität.

Sie wissen vielleicht sogar nicht über private Methoden, bevor Sie bestimmte Klassen implementieren. Aber da Sie eine Reihe von RED Tests haben, ist die eine Sache, die Sie tun müssen, sie grün zu machen. Es spielt keine Rolle, wie Sie es tun werden (öffentliche oder private Methoden).

Ein Ziel Nummer eins ist es, minimale Zeilen Code schreiben, die durch die Unit-Tests abgedeckt werden sollte. Ich habe TDD topic tiefer auf meinem Blog behandelt.