Как правильно управлять тестированием?

Question

Я читал о TDD, и я попробовал его в своем новом проекте.

Я понимаю, что в TDD это как тестирование Blackbox, то есть это имеет значение , что, а не как .so, я пришел к выводу и перестал испытывать частные методы после прочтения об этом на многих постах, как это неверный путь.

Однако я не смог это сделать по этим причинам.

Я покажу вам пример: У меня есть программа, которая читает текстовый абзац, поэтому я написал что-то подобное в своем методе тестирования (для tdd step1).

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

Итак, соответственно, я сделал этот метод, чтобы создать RED случай.

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

Я написал следующий код:

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 
    } 


} 

Теперь проблема, я заранее знаю, что я буду использовать countingwords и createCustomParagraph как частные методы.

Таким образом, в том, что случаях я должен идти с:

1. создания их общественности и следовать TDD цикл.

2. сделать их частными.

3. удалить тесты для них (поскольку методы теперь являются частными и недоступными для тестов). Я думаю, что это довольно громоздкий и неправильный способ сделать tdd.

Я смущен о this.Everyone говорит код записи только после того, как вы пишете провальный тест, но вот если я знаю, что я собираюсь написать частный метод то как мне это сделать?

Прошу вас исправить меня, если я где-то ошибаюсь. Кроме того, если возможно дать некоторый реальный пример ...

Кроме того, я боюсь, что большую часть времени я буду тесты для редактирования или удаления их из-за проблем спецификаторов доступа или рефакторинга ...

Примечание: есть нет a дубликат вопрос. У меня нет хорошего ответа для ситуаций в реальном времени. Во всех примерах, которые я видел, они показывают только один класс с спецификаторами по умолчанию или с открытым доступом, поэтому они действительно не показывают, как именно работать в реальном времени.

Answer 1

Из моего личного опыта вы тестируете класс и интерфейс для класса остальной частью вашего приложения. Ваши тестовые примеры TDD должны быть написаны против общедоступных методов вашего класса.Дело в том, чтобы проверить, что при стимулировании класс выводит желаемые результаты для прохождения ваших тестовых критериев. Внутренние частные методы будут протестированы как часть тестирования публичного интерфейса, но цель состоит в том, чтобы проверить, работает ли общедоступный интерфейс. Вы говорите, что знаете заранее, что частные методы будут использоваться, но если кто-то реорганизует, как делаются в классе, не изменяя внешнего поведения, вы все равно сможете использовать существующие тесты и убедитесь, что рефакторинг не нарушил ранее работающий метод.

Answer 2

Если метод является деталью реализации основной вещи, которую вы строите, которая должна оставаться конфиденциальной, это не означает, что нет возможности написать для нее тест. Вы можете сделать эту функциональную часть другого класса, где она может быть общедоступной, написание тестов, которые осуществляют ее непосредственно, а затем называть это конфиденциально из основной вещи. Таким образом, вы можете протестировать частные методы, никакие тесты не будут удалены, и вам не придется проходить через искажения, проверяя что-то косвенно, когда используемая вещь может не предоставлять доступ ко всему, что вы хотите проверить. И теперь вместо того, чтобы иметь частные методы, которые являются скрытыми битами gnarly кода, у вас есть хорошо протестированные строительные блоки, готовые к повторному использованию в другом месте.

Answer 3

Очень хороший вопрос. Я тоже много раз спрашивал. И вообще ответы говорят, что вам нужно подумать об модульных тестах, которые идут до реализации основных функциональных возможностей, таких как кадров. Эти рамки строго определяют функциональность.

Таким образом, вы даже можете не знать о частных методах, прежде чем вы собираетесь реализовать некоторые определенные классы. Но поскольку у вас есть набор тестов RED, вы должны сделать это, чтобы сделать их зелеными. Неважно, как вы это сделаете (публичные или частные методы).

Цель номер один - написать минимальные строки кода, которые должны быть покрыты . Я более подробно описал в своем блоге TDD topic.