Я понимаю разработку, основанную на тестировании, что вам разрешено писать продуктивный код только при неудачном (красном) модульном тесте.
Нет. Вы можете написать только самый простой код, чтобы изменить сообщение теста. Это ничего не говорит о том, что за тест.
Фактически, вы, вероятно, начнете с того, что напишите неуспешный (красный) приемочный тест для критерия приемки, точнее, вы напишете простейший приемочный тест, который может оказаться неудачным; после этого вы запускаете тест, наблюдаете, как он проваливается, и проверяете, что он не прошел по правильной причине. Затем вы пишете ошибочный функциональный тест для части функциональности этого критерия приемлемости, опять же, вы пишете простейший функциональный тест, который может быть неудачным, запускаете его, наблюдаете, как он отказывает, и проверяете, что он выходит из строя по правильной причине. Затем вы пишете провальный модульный тест, самый простой модульный тест, который может быть неудачным, запускаете его, смотрите, как он проваливается, проверяете, что он проваливается по правильной причине.
Теперь вы пишете простейший производственный код, который может изменить сообщение об ошибке. Запустите тест снова, убедитесь, что сообщение об ошибке изменилось, что оно изменилось в правильном направлении, и что код изменил сообщение по правильной причине. (В идеале, сообщение об ошибке должно исчезнуть, и тест должен пройти, но чаще всего лучше сделать небольшие изменения, изменяя сообщение, а не пытаться заставить тест пройти тест за один раз - вот причина почему разработчики тестовых сред тратят столько усилий на сообщения об ошибках!)
После прохождения модульного теста вы реорганизуете производственный код под защитой ваших тестов. (Обратите внимание, что в настоящее время приемочный тест и функциональный тест по-прежнему не проходят, но это нормально, поскольку вы выполняете рефакторинг только отдельных модулей, которые охватываются модульными тестами.)
Теперь вы создаете следующий модульный тест и повторяете вышеизложенное, пока функциональный тест также не пройдет. Под защитой функционального теста вы можете выполнять рефакторинг для нескольких устройств.
Этот средний цикл теперь повторяется до тех пор, пока не пройдет приемочный тест, и теперь вы можете выполнять рефакторинг по всей системе.
Теперь вы выбираете следующий критерий принятия, и внешний цикл начинается снова.
Кент Бек, «первооткрыватель» TDD (ему не нравится термин «изобретатель», он говорит, что люди этим занимались все время, он просто дал ему имя и написал об этом книгу) использует аналогию из фотографии и называет это "увеличение и уменьшение".
Примечание: вам не всегда нужны три уровня тестов. Может быть, иногда тебе нужно больше. Чаще вам нужно меньше. Если ваши функциональные возможности невелики, а функциональные тесты выполняются быстро, вы можете обойтись без (или с меньшим количеством юнит-тестов). Часто вам нужны только приемочные испытания и юнит-тесты. Или ваши критерии приемки настолько детализированы, что приемочные тесты - это функциональные тесты.
Кент Бек говорит, что если у него есть быстрый, маленький и сфокусированный функциональный тест, он сначала напишет модульные тесты, позволит модульным тестам управлять кодом, а затем снова удалит (некоторые из) модульных тестов, которые охватывают код, который также покрыты быстрым функциональным тестом. Помните: тестовый код также является кодом, который необходимо поддерживать и реорганизовывать, чем меньше его, тем лучше!
Однако мне интересно, может ли подход, основанный на тестировании, применяться и к другим формам тестов.
Вы действительно не применяете TDD к тестам. Вы применяете это ко всему процессу разработки. Вот что означает «управляемая» часть Test- Driven -Development: вся ваша разработка основана на тестах. Тесты не только управляют кодом, который вы пишете, они также определяют, какой код писать, какой код писать дальше. Они управляют вашим дизайном. Они скажут вам, когда вы закончите. Они говорят вам, над чем работать дальше. Они рассказывают вам о недостатках дизайна в вашем коде (когда тесты трудно писать).
Кейт Брейтуэйт создал упражнение, которое он называет TDD, как будто вы это имели в виду . Он состоит из набора правил (основанных на Трех правилах TDD дяди Боба Мартина , но гораздо более строгих), которым вы должны строго следовать и которые направлены на то, чтобы более строго применять TDD. Лучше всего работает с парным программированием (чтобы ваша пара могла убедиться, что вы не нарушаете правила) и с инструктором.
Правила таковы:
- Напишите ровно один новый тест, самый маленький тест, который вы, возможно, указывает на решение
- Видеть это не удастся; ошибки компиляции считаются ошибками
- Пройдите тест из (1), написав наименьший код реализации, который вы можете использовать в методе test .
- Рефакторинг для устранения дублирования, а также по мере необходимости для улучшения дизайна. Будьте строги в использовании этих ходов:
- вам нужен новый метод - дождитесь времени рефакторинга, затем ... создайте новые (не тестовые) методы, выполнив один из них, и никак иначе:
- предпочтительнее: сделать метод извлечения для кода реализации, созданного в соответствии с (3), чтобы создать новый метод в тестовом классе, или
- если вы должны: переместить код реализации согласно (3) в существующий метод реализации
- Вы хотите новый класс - подождите до времени рефакторинга, затем ... создайте не тестовые классы, чтобы обеспечить назначение для метода Move, и ни по какой другой причине
- заполнить классы реализации методами, выполнив Move Method, и никак иначе
Эти правила предназначены для осуществления TDD. Они не предназначены для фактического использования TDD на производстве (хотя ничто не мешает вам опробовать его). Они могут чувствовать разочарование, потому что иногда кажется, что вы делаете тысячи маленьких маленьких шагов, не добиваясь реального прогресса.
