Я начинаю использовать разработку через тестирование для JavaScript, но я хотел бы начать использовать ее в своих разных проектах.
Хотелось бы узнать, какие типичные ошибки и как их избежать?
Кроме того, я хотел бы знать, что мне следует прочитать, чтобы облегчить изучение и применение разработки через тестирование к моему коду.
Заранее спасибо.
Самая большая проблема, с которой я столкнулся при использовании TDD, заключается в том, что разработчики не уверены в модульном тестировании. Плохое модульное тестирование тратит больше времени, чем экономит. Запутанные, ненадежные, неподдерживаемые, нечитаемые тесты очень быстро отходят на второй план, и измученным разработчикам нужно время, чтобы снова захотеть автоматически проводить модульное тестирование.
Пер Фагрелл делает несколько хороших замечаний, особенно в отношении запуска тестов после каждого изменения; выполнение тестов до и после любого изменения теста должно стать вашей второй натурой.
Фреймворки:
Используйте QUnit в качестве основы для тестирования JS: http://docs.jquery.com/Qunit
У меня есть тестовая страница с зависимой разметкой, и тесты очень хорошо работают при загрузке страницы.
Вы можете следить за
поток для модульных тестов с использованием QUnit.
Однако вам придется вручную реализовывать методы настройки и разрыва теста и вызывать их в своих методах тестирования. Это поможет изолировать тестовые случаи, сохраняя одинаковые условия для всех тестов и предотвращая зависимость тестов от порядка их выполнения.
Ищите полезные фреймворки на других языках, которые вы будете использовать. NUnit очень популярен для .NET.
Изоляция:
Пер Фагрелл также делает хорошее замечание по поводу изоляции. Различие между модульным тестированием (проверкой одного аспекта функциональности атома) и интеграцией (проверкой того, как несколько атомов работают вместе) следует хорошо понимать перед началом тестирования. Если у вас более одного утверждения в методе тестирования, вы не выполняете модульное тестирование и вам необходимо изменить метод тестирования.
Условия:
Хорошее соглашение об именах из отличного Искусство модульного тестирования для ваших тестов MethodUnderTest_Condition_ExpectedBehaviour, например
Expand_TextVariable_ExpandsText
Из та же книга сохраните свои тесты:
В противном случае вы и другие разработчики не будете проводить тесты.
Подделки:
Распространенным заблуждением является различие между двумя типами подделок: заглушки и насмешки.
Шов создается в коде путем абстрагирования функций, от которых зависит код, в интерфейс. Например. Контроллер не зависит от конкретного репозитория, он будет зависеть от IRepository.
Затем заглушка реализует этот IRepository и возвращает поддельные значения; он используется для изолированного выполнения кода контроллера. например GetCustomer() создаст нового клиента и вернет его без обращений к настоящему репозиторию или любому магазину. Заглушки никогда не тестируются.
Макет похож на заглушку, за исключением того, что он может содержать значения, с которыми можно сравнивать. например AddCustomer(Customer customerToBeAdded), ваш макет примет это значение и может быть опровергнут. Имитации можно протестировать.
Взгляните на Test Isolation Framework (или Mocking Framework), который может автоматически создавать подделки для данного интерфейса.
Неправильное понимание цели макетов привело к тому, что несколько разработчиков, которых я видел, создавали макет для проверки функциональности, а затем писали тесты против самих макетов.
Ресурсы:
Я уже упоминал Искусство модульного тестирования, и я настоятельно рекомендую его. Это одна из книг, наряду с Code Complete, которую я бы схватил, если бы офис загорелся.
Надеюсь, это поможет.
Убедитесь, что ваши тесты проверяют только одну часть функциональности. Имя и утверждения также должны быть полностью согласованы с этим. Например. если вы добавляете функцию expand() в обработчик переменных, тогда тест должен называться (примерно) test_expands_variables или should_expand_defined_variable или как угодно, что соответствует вашему соглашению об именах, а утверждения должны быть только в возвращаемое значение или побочные эффекты вызова функции. Распространенной ошибкой является утверждение шагов настройки, но любая функциональность в настройке должна иметь свой собственный тест с уже установленным именно этим утверждением. Если вы утверждаете одно и то же везде, внезапно становится трудно понять, какой тест вы должны исправлять.
Хорошей отправной точкой для того, чтобы прочувствовать весь цикл TDD, будет попробовать некоторые кодовые ката. Конвертер римских цифр – обычное первое введение. писать тесты в первую очередь. В начале будьте ДЕЙСТВИТЕЛЬНО внимательны к запуску тестов после каждого небольшого изменения. Как только вы освоитесь, вы почувствуете, насколько навязчивым вам нужно/должно быть, но для новичка обычно требуется быть очень педантичным.
Я начал знакомиться с TDD в Javascript с книги Кристиана Йохансена «Разработка JavaScript через тестирование». Он превосходен и охватывает почти все аспекты TDD и применяет его к JS: http://tddjs.com/
