Тестирование модулей и тестирование белого ящика

Question

В настоящее время я нахожусь в положении, когда я должен написать модульные тесты для исходного кода. У меня есть полная видимость (что, на мой взгляд, означает, что это считается тестированием белого ящика?). Таким образом, это не тестовое развитие.

Чтение этого (What is the difference between integration and unit tests?) разъясняло многое о том, для чего цель всего этого, но я все еще смущен о моем текущем положении.

Скажем, у меня есть метод, как так:

/* Some basic description on what doSomething() does */ 
public int doSomething(Var someVariable) { 
    int someInteger = [code does a bunch of stuff to get this]; 
    someInteger = someOtherClassObject.doSomethingElse(someInteger); 
    return someInteger; 
} 

Теперь, я не знаю, что doSomething() должен делать. Документации недостаточно для того, чтобы действительно сказать мне, что int предположительно выйдет на основе someVariable, и я недостаточно разбираюсь в исходном коде, чтобы действительно придумать его сам.

Но у меня есть реализация, поэтому я смотрю на метод, положить в некоторых Var в качестве входа, и следовать кодексу и утверждать, против того, что он выглядит, как он бы возвращения.

public void testDoSomething() { 
    ClassWithDoSomething object = new ClassWithDoSomething(); 
    assertEquals([what it looks like it would return], object.doSomething(new Var([some input would go here])); 
} 

Где каким-то образом, каким-то образом, я дразнить из вызова doSomethingElse() и конструктор Var (и других зависимостей внешнего класса, если это необходимо).

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

Ответ, который я прочитал, подробно описывает, как модульные тесты полезны из-за изолированного отказа метода doSomething(). Но когда будет выполняться его единичный тест, кроме того, когда изменяется реализация приложения doSomething() (что будет означать изменение в модульном тесте)?

Является ли это проблемой не слишком хорошо зная исходный код/​​исходный код недостаточно хорошо документирован, чтобы просто знать, какой результат я должен получать?

Если [code does a bunch of stuff to get this] был на самом деле просто someVariable + 3 где someVariable был Int, она считается содержательной Assert утверждать, что возвращаемое значение someVariable + 3, когда я знаю, что тест будет проходить на основе этой реализации?

Answer 1

Но когда будет выполняться его единичный тест?

У вас есть это точно; при выполнении изменений в модуле doSomething произойдет сбой. Точка модульного теста заключается в том, чтобы поймать его, когда казалось бы, безобидное изменение действительно нарушает метод.

Юнит тесты часто похожи на фрагмент кода, отвечал:

public void testDoSomething() { 
    ClassWithDoSomething object = new ClassWithDoSomething(); 
    object.someOtherClassObject = new MockOtherClass(); 
    assertEquals(4, object.doSomething(new Var("Input that maps to 4")); 
} 

Оба SomeOtherClass и MockOtherClass реализовать IOtherClass интерфейс, который определяет doSomethingElse. MockOtherClass просто возвращает ввод, когда вы вызываете его метод doSomethingElse.

Answer 2

Я бы сказал, что бессмысленно писать модульное тестирование, если вы не знаете, что должен делать код. модульное тестирование проверяет правильность поведения какого-либо входного кода. если вы не знаете, что означает «правильно», то как вы можете его протестировать? вы должны понимать намерение кода перед написанием ценных тестов.

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

поэтому я рекомендую всегда знать намерение кода, прежде чем писать тесты.