Я экспериментирую с разработкой на основе тестов и обнаружил, что часто сталкиваюсь со следующей ситуацией:
- Я пишу тесты для некоторой функциональности X. Эти тесты не проходят.
- Пытаясь реализовать X, я вижу, что мне нужно реализовать некоторую функцию Y на нижнем уровне моего кода. Так...
- Я пишу тесты для Y. Теперь оба теста для X и Y не пройдены.
Однажды у меня было 4 функции в разных слоях кода, над которыми работали одновременно, и я терял свое внимание к тому, что я на самом деле делаю (слишком много тестов проваливалось одновременно).
Я думаю, что смогу решить эту проблему, приложив больше усилий к планированию своих задач еще до того, как начну писать тесты. Но в некоторых случаях я не знал, что мне нужно идти глубже, потому что, например, я не очень хорошо знал API нижнего уровня.
Что мне делать в таких случаях? Есть ли у TDD какие-либо рекомендации?
источник
X
я должен знать, какую часть зависимостейX
мне нужно смоделировать. Я чувствую, что это часть деталей реализации, которая не должна быть частью тестов, иначе мне может понадобиться изменить тесты при рефакторинге реализации. Должен ли я беспокоиться об этом?Заглушки и макеты могут быть использованы для имитации функциональности, которая еще не была изменена / реализована. Они также могут помочь вам разрешить зависимости, которые вызывают подобную «цепную реакцию».
С другой стороны, возможно, лучше всего сохранить только один (провальный) тест, который приведет к следующему изменению.
Другие тесты, которые нацелены на код, который опирается на новые функциональные возможности, могут быть временно отключены, поскольку они на самом деле не имеют отношения к этому моменту, т.е. в вашем случае отключайте тесты для X, пока не внедрите Y и т. д.
Таким образом, вы сможете сосредоточиться только на следующих изменениях, что, я думаю, вам и нужно.
источник
unittest
уже есть тестовые пропуски. Это может быть достаточно для меня.Стоп
Неожиданно, похоже, что здесь могут быть две отдельные проблемы:
Вы забыли некоторые истории и тестовые сценарии и не обнаружили их, пока не начали работать над конкретным тестовым сценарием и / или
вы на самом деле делать модульное тестирование, а не TDD функции тестирования
Для # 1 остановитесь , вернитесь назад и обновите истории и тестовые сценарии, затем начните сначала с другого сценария.
Что касается # 2, остановитесь и помните, что вы тестируете функции, а не модули, поэтому используйте макеты, чтобы замаскировать другие интерфейсы и / или внедрить больше кода для прохождения теста без добавления новых сценариев тестирования. Это предполагает, что вы не пропускаете тестовые сценарии, а вместо этого - и это действительно часто встречается - совмещая модульное тестирование и TDD.
источник
Это большой вопрос и огромное разочарование для меня, а также TDD. Я чувствую, что TDD не хватает в этом сценарии, когда у вас просто нет возможности узнать, какие компоненты или функции более низкого уровня вам понадобятся, пока вы не начнете разработку.
Лично я обнаружил, что TDD работает, только если вы точно знаете, что вам нужно делать, и что вам нужно для вызова функции. Разработчики не всегда знают все до того, как мы начнем, поэтому я нашел для себя лучший способ смягчить ситуацию, которую вы описываете:
Опытный образец
Когда я делаю простые приложения-прототипы, чтобы исследовать и открывать методы и подходы к технической проблеме, я обнаруживаю большую часть работы и ухожу это исследование до того, как я начну. Проектирование и оценка также становятся намного проще.
Если прототип должен быть настолько вовлечен, что он становится приложением, тогда я призываю вас не делать ленивых вещей и собирать юнит-тесты для вашего прототипа по факту.
Вы должны знать больше об API нижнего уровня на этом этапе и быть в состоянии успешно смоделировать API нижнего уровня в ваших компонентах более высокого уровня.
источник
Это зависит от того, какие тесты вы пишете во время выполнения TDD.
Классическая модель заключается в написании модульных тестов и использовании макетов или заглушек для отделения теста от других «блоков» кода.
Существует много других альтернативных моделей, таких как ATDD, в которых тестируется полный стек, или тест почти полного стека. В этом конкретном случае ваши тесты написания, которые утверждают, что требуется поведение программы, а не единица кода, поэтому вы не будете писать другие тесты. Вы бы получили агрегат туда и обратно, чтобы выполнить тест. Затем вы добавляете другие тесты для других функций / поведения.
источник