Может ли кто-нибудь объяснить "Подделка, пока вы не сделаете это" в Test Driven Development?

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

Хорошо, вы подделали это, допустим, вы вернули константу, чтобы сломанный тест был зеленым в начале. Затем вы повторно учли свой код. Затем вы запускаете тот же тест, который будет проходить, очевидно, потому, что вы подделали его!

Но если тест проходит, как вы можете положиться на это, особенно когда вы знаете, что вы это подделывали?

Как следует подвергнуть фальсифицированному тестированию реальный рефакторинг кода, чтобы он мог быть надежным?

Спасибо

Ответ 1

Сначала вы создаете unit test тестирование новой функциональности, которая не существует.

Теперь у вас есть unit test к существующему методу. Затем вы создаете этот метод, который ничего не делает, и ваши компиляторы unit test, но, конечно, терпят неудачу.

Затем вы продолжаете создавать свой метод, базовые функции и т.д., пока ваш unit test не удастся.

Это (вид) тестового развития.

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

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

Ответ 2

Короткий ответ: напишите больше тестов.

Если метод возвращает константу (когда она должна что-то вычислять), просто добавьте тест для условия с другим результатом. Итак, скажем, у вас было следующее:

@Test
public void testLength()
{
    final int result = objectUnderTest.myLength("hello");
    assertEquals(5, result);
}

и myLength были реализованы как return 5, тогда вы пишете аналогичный (дополнительный) тест, но передаете в "foobar" вместо этого и утверждаете, что вывод равен 6.

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

Ответ 3

Подделайте его, пока вы не попросите его написать простейшую возможную вещь, чтобы передать ваши текущие тесты. Часто, когда вы написали один тестовый пример для новой функции, самым простым способом является возвращение константы. Когда что-то простое удовлетворяет вашим тестам, это потому, что у вас пока нет достаточных тестов. Поэтому напишите еще один тест, как говорит @Andrzej Doyle. Теперь вам нужна какая-то логика. Возможно, на этот раз самое простое - написать очень основную логику if-else для обработки ваших двух тестовых примеров. Вы знаете, что вы это притворяетесь, поэтому вы знаете, что вы не закончили. Когда становится проще писать фактический код для решения вашей проблемы, чем продлить вашу подделку, чтобы охватить еще один тестовый пример - то, что вы делаете. И у вас достаточно тестовых примеров, чтобы убедиться, что вы правильно их пишете.

Ответ 4

Это может быть ссылка на практику использования mocks/stubs/ подделок, с которыми сотрудничает ваша тестовая система/класс.

В этом случае вы "подделываете" сотрудника, а не то, что вы тестируете, потому что у вас нет реализации этого интерфейса для соавторов.

Таким образом, вы подделываете его до тех пор, пока вы не "сделаете это", это означает, что вы реализуете его в конкретном классе.

Ответ 5

В TDD все требования выражаются в виде тестов. Если вы подделываете что-то и все тесты проходят, ваши требования выполняются. Если это не дает вам ожидаемого поведения, вы не указали все свои требования в качестве тестов.

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