Какие режимы отказов может оставить TDD?
Обратите внимание, что я еще не «увидел свет» на TDD, и действительно не получил , почему он имеет все преимущества, проповедуемые его Основные сторонники. Я не отрицаю это - у меня просто есть свои сомнения, которые, вероятно, рождены невежеством. Так что, конечно, смейтесь над вопросами ниже, пока вы можете исправить меня: -)
Может ли использование TDD оставить себя открытым для непреднамеренных побочных эффектов вашей реализации? Концепция «наименьшего количества кода, удовлетворяющего тесту» предлагает думать в самых узких терминах о конкретной проблеме, не обязательно созерцая общую картину.
Я имею в виду объекты, которые содержат или зависят от состояния (например, внутреннее поле ценности). Если у вас есть тесты, которые создают объект изолированно, Инициализируйте этот объект, а затем вызовите тестируемый метод. Как вы обнаружите, что другой другой метод оставил недопустимое состояние, которое отрицательно скажется на поведении первого метода? Если я правильно понял вопросы, то вам не следует полагаться на порядок выполнения теста.
Другие сбои, которые я могу себе представить, включают в себя закрытие потоков, неиспользование объектов GDI + и тому подобное.
Является ли это даже проблемная область TDD, или интеграция и системное тестирование должны улавливать такие проблемы?
Спасибо в ожидании ....
4 ответа
Часть этого находится в области TDD.
Дэн Норт говорит, что разработки через тестирование не существует; что на самом деле мы занимаемся разработкой на основе примеров, а примеры становятся регрессионными тестами только после того, как тестируемая система реализована.
Это означает, что при разработке фрагмента кода вы рассматриваете примеры сценариев и устанавливаете тесты для каждого из этих случаев. Эти случаи должны включать возможность того, что данные недействительны, без учета почему данные могут быть недействительны.
Такие вещи, как закрытие потока, могут и должны быть рассмотрены во время практики TDD.
Мы используем такие конструкции, как функции, не только для уменьшения дублирования, но и для инкапсуляции функциональности. Мы уменьшаем побочные эффекты, поддерживая эту инкапсуляцию. Я бы сказал, что мы рассматриваем более широкую картину с точки зрения дизайна, но когда дело доходит до реализации метода, мы должны иметь возможность сузить наше внимание до этой области — этой единицы функциональности. Когда мы начинаем жонглировать внешними факторами, мы, вероятно, создаем дефекты.
Во всяком случае, это мое мнение; другие могут видеть это по-другому.
Хорошие вопросы. Вот мои два цента, основанные на моем личном опыте:
Может ли использование TDD оставить вас открытым для непреднамеренные побочные эффекты вашего выполнение?
Да, это так. TDD не является «полноценным» вариантом. Его следует использовать вместе с другими методами, и вы обязательно должны иметь в виду общую картину (независимо от того, несете ли вы за нее ответственность или нет).
Я думаю об объектах, которые удерживают или зависит от состояния (например, внутреннее поле ценности).Если у вас есть тесты, которые создать экземпляр объекта изолированно, инициализируйте этот объект, а затем вызовите тестируемый метод, как бы вы пятно, что другой метод оставил за недопустимым состоянием, которое негативно сказаться на поведении первый способ? Если я понял имеет значение правильно, то вы не должны полагаться на порядок выполнения теста.
Каждый тестовый метод должен выполняться независимо от того, что было выполнено до или будет выполняться после. Если это не так, то что-то не так (с точки зрения TDD).
Говоря о вашем примере, когда вы пишете тест, вы должны достаточно подробно знать, какие будут ваши входные данные и каковы ожидаемые результаты. Вы начинаете с определенного входа в определенном состоянии и проверяете желаемый результат. У вас нет стопроцентной гарантии, что тот же метод в другом состоянии будет выполнять свою работу без ошибок. Однако «неожиданное» должно быть сведено к минимуму.
Если вы проектируете класс, вы обязательно должны знать, могут ли два метода изменить некоторое общее внутреннее состояние и как; и, что более важно, должно ли это действительно произойти вообще, или есть ли проблема низкой сплоченности.
В любом случае, хороший дизайн на уровне «tdd» не обязательно означает, что ваше программное обеспечение хорошо построено, вам нужно больше, как хорошо объясняет дядя Боб здесь:
http://blog.objectmentor.com/articles/ 17.10.2007/tdd-with-acceptance-tests-and-unit-tests
Мартин Фаулер написал интересную статью о тесте Mocks vs Stubs, в которой рассматриваются некоторые темы, о которых вы говорите:
http:/ /мартинфаулер.com/articles/mocksArentStubs.html#ClassicalAndMockistTesting
Понятие «наименьшее количество код для выполнения теста" предлагает мыслить в самых узких терминах о конкретная проблема без обязательно созерцая большее рисунок.
Это предполагает это, но это не то, что это означает. Это означает мощные шоры на данный момент. Общая картина есть, но она мешает выполнению текущей задачи, поэтому полностью сосредоточьтесь на ней, а затем беспокойтесь о том, что будет дальше. Общая картина присутствует, учитывается в TDD, но мы приостанавливаем на ней внимание на этапе Red. Пока есть непройденный тест, наша задача состоит в том, чтобы этот тест прошел. Как только он и все другие тесты пройдены, пришло время подумать об общей картине, посмотреть на недостатки, предвидеть новые режимы отказа, новые входные данные — и написать тест, чтобы выразить их. Это возвращает нас к Красному и снова сужает наше внимание. Пройдите новый тест, а затем отложите шоры для следующего шага вперед.
Да, TDD дает нам шоры. Но это не ослепляет нас.
TDD не является заменой быть умным. Лучшие программисты становятся еще лучше благодаря TDD. Худшие программисты по-прежнему ужасны.
Тот факт, что вы задаете эти вопросы, является хорошим признаком: это означает, что вы серьезно относитесь к программированию.
Понятие «наименьшее количество код для выполнения теста" предлагает мыслить в самых узких терминах о конкретная проблема без обязательно созерцая большее рисунок.
Такую позицию легко принять, например: «Мне не нужно это проверять, я уверен, что это просто работает». Оба наивны.
На самом деле речь идет о маленьких шагах, а не о том, чтобы сдаться раньше времени. Вы по-прежнему стремитесь к отличному конечному результату, но по пути тщательно обосновываете и проверяете каждый бит кода, который вы пишете, с помощью теста.
Непосредственная цель TDD довольно узка: «как я могу быть уверен, что код, который я пишу, делает то, что я намереваюсь сделать?» Если у вас есть другие вопросы, на которые вы хотите ответить ( например, «хорошо ли это пройдет в Гане?» и «достаточно ли быстро работает моя программа?»), то вам потребуются разные подходы, чтобы ответить на них.
Я думаю об объектах, которые держат или зависят от штата.
как бы вы заметили другое метод оставил недопустимый государство?
Зависимости и состояние создают проблемы. Они создают тонкие ошибки, которые появляются в самые неподходящие моменты. Они усложняют рефакторинг и дальнейшее усовершенствование. И они делают модульное тестирование невозможным.
К счастью, TDD отлично помогает создавать код, который изолирует вашу логику от зависимостей и состояний. Это вторая "D" в "TDD".