Какие режимы отказов может оставить TDD?

Question

Обратите внимание, что я еще не «увидел свет» на TDD, и действительно не получил , почему он имеет все преимущества, проповедуемые его основными сторонниками.Я не отклоняю это - у меня просто есть мои оговорки, которые, вероятно, рождены невежеством.Так что, конечно, смейтесь над вопросами ниже, пока вы можете исправить меня: -)

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

Я имею в виду объекты, которые содержат или зависят от состояния (например, значения внутреннего поля).Если у вас есть тесты, которые создают экземпляр объекта изолированно, инициализируйте этот объект, а затем вызовите тестируемый метод, как вы заметите, что метод другой оставил недопустимое состояние, которое могло бы неблагоприятно повлиять на поведениепервый метод?Если я правильно понял вопросы, то вам не следует полагаться на порядок выполнения теста.

Другие возможные сбои, которые я могу себе представить, включают в себя закрытие потоков, неиспользование объектов GDI + и тому подобное.

Это даже проблемная область TDD, или интеграция и системное тестирование должны улавливать такие проблемы?

Спасибо в ожидании ....

Answer 1

Часть этого находится в области TDD.

Дэн Норт говорит, что нет такой вещи, как разработка через тестирование; то, что мы на самом деле делаем, - это разработка на основе примеров, и примеры становятся регрессионными тестами только после внедрения тестируемой системы.

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

Что-то вроде закрытия потока может и должно быть абсолютно обязательно при практике TDD.

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

Во всяком случае, это мой дубль; другие могут увидеть это по-другому.

Answer 2

TDD не заменяет умного. Лучшие программисты становятся еще лучше с TDD. Худшие программисты все еще ужасны.

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

Понятие «наименьшее количество код для удовлетворения теста "предлагает думать в самом узком смысле о конкретная проблема без обязательно созерцая больше изображение.

Это легко принять, просто как «мне не нужно это проверять; я уверен, что это просто работает». Оба наивны.

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

Непосредственная цель TDD довольно узка: " как я могу быть уверен, что код, который я пишу, делает то, что я собираюсь сделать? " Если у вас есть другие вопросы, на которые вы хотите ответить ( типа «будет ли это хорошо в Гане?» и «достаточно ли моя программа будет достаточно быстрой?») тогда вам понадобятся разные подходы, чтобы ответить на них.

Я думаю об объектах, которые содержат или зависит от государства.

как бы вы заметили, что отличается метод оставил недействительным состояние

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

К счастью, TDD отлично помогает вам создавать код, который изолирует вашу логику от зависимостей и состояний. Это вторая буква "D" в "TDD".

Answer 3

Понятие «наименьшее количество код для удовлетворения теста "предлагает думать в самом узком смысле о конкретная проблема без обязательно созерцая больше изображение.

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

Да, TDD дает нам шоры. Но это не ослепляет нас.

Answer 4

Хорошие вопросы.Вот мои два цента, основанные на моем личном опыте:

Может ли использование TDD оставить вас открытым для непреднамеренных побочных эффектов вашей реализации?

Да, так и есть.TDD не является «полноценным» вариантом.Его следует использовать вместе с другими техниками, и вам обязательно следует иметь в виду общую картину (независимо от того, несете вы за это ответственность или нет).

Я имею в виду объекты, которые содержат или зависят отсостояние (например, значения внутреннего поля).Если у вас есть тесты, которые создают экземпляр изолированного объекта, инициализируют этот объект, а затем вызывают тестируемый метод, как вы заметите, что другой метод оставил недопустимое состояние, которое может отрицательно повлиять на поведение первого метода?Если я правильно понял вопросы, вы не должны полагаться на порядок выполнения теста.

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

Говоря о своем примере, когда вы пишете тест, вы должны знать с достаточной детализацией, какие будут ваши входные данные и каковы ожидаемые результаты.выходы.Вы начинаете с определенного входа, в определенном состоянии, и вы проверяете желаемый выход.Вы не гарантированы на 100%, что тот же метод в другом состоянии выполнит свою работу без ошибок.Однако «неожиданное» должно быть сведено к минимуму.

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

В любом случае, хороший дизайн на уровне "tdd" не обязательно означает, чтоВаше программное обеспечение хорошо построено, вам нужно больше, как хорошо объясняет здесь дядя Боб:

http://blog.objectmentor.com/articles/2007/10/17/tdd-with-acceptance-tests-and-unit-tests

Мартин Фаулер написал интересную статью о тесте Mocks vs Stubs, которая охватывает некоторые темы, которые выговорить о:

http://martinfowler.com/articles/mocksArentStubs.html#ClassicalAndMockistTesting