Может кто-нибудь объяснить подход «Фальсифицируй, пока не сделаешь» в Test Driven Development?

Question

У меня проблема с пониманием эволюции кода, когда вы применили подход TDD «Фальсифицируйте, пока не сделаете».

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

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

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

Спасибо

Answer 1

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

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

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

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

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

Answer 2

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

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

Затем вы продолжаете строить свой метод, базовую функциональность и т. Д., Пока ваш модульный тест не будет успешным.1006 * Это (своего рода) разработка, основанная на тестировании.

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

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

Answer 3

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

Answer 4

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

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

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

Answer 5

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

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