Можно ли использовать сразу несколько сред тестирования?
Некоторые проекты программного обеспечения с открытым исходным кодом действительно используют несколько сред тестирования. Обычной установкой может быть использование инфраструктуры модульного тестирования с инфраструктурой макетов, если разработчики проекта не хотят создавать свои собственные макеты.
Итак, когда вы достигнете избыточного тестирования юнитов ?
Вы быстро достигнете юнит-тестирования "перебор" и, возможно, уже достигли его. В целом, существует несколько способов переусердствовать с тестированием, которое противоречит цели TDD , BDD , ADD и любому подходу, который вы используете. Вот один из них:
Превышение модульного тестирования достигается, когда вы начинаете писать другие типы тестов, как если бы они были модульными тестами. Предполагается, что это должно быть исправлено с помощью фальшивых фреймворков (для тестирования взаимодействий, изолированных только для одного класса) и спецификационных фреймворков (для тестирования функций и определенных требований). Многие разработчики путают, кажется, что это хорошая идея - обрабатывать все типы тестов одинаково, что приводит к некоторым грязным гибридам .
Несмотря на то, что TDD фокусируется на модульном тестировании, вы все равно будете писать функциональные тесты, тесты интеграции и производительности. Однако вы должны напомнить себе, что их область действия сильно отличается от юнит-тестов. Вот почему доступно так много инструментов тестирования, так как существуют различные типы тестов. Нет ничего плохого в использовании многих платформ тестирования, и большинство из них совместимы друг с другом.
Таким образом, при написании модульных тестов есть пара приятных мест , о которых следует помнить при написании тестов:
unit test dirty hybrids integration test
--------- ------------- ----------------
* isolated * using many classes
* well defined | * tests a larger feature
* repeatable | * tests a data set
|
| | |
| | |
v v v
O <-----------------------------------------------------> O
^ ^ ^
| | |
sweet spot world full of pain sweet spot
Юнит-тесты легко написать, и вы хотите написать их много. Но если вы напишете тест, который имеет слишком много зависимостей, вы закончите с большой работой, как только требования начнут меняться. Когда код ломается в модульном тесте, который имеет слишком много зависимостей, вы должны проверять код многих классов, а не один и только один класс. Это означает, что вы должны проверить все его зависимости, чтобы увидеть, где проблема, которая противоречит цели модульного тестирования в смысле TDD. В большом проекте это было бы невероятно много времени.
Мораль этой истории в том, что не путайте юнит-тесты с интеграционными тестами. Потому что просто: они разные . Это не означает, что тесты других типов плохие, но вместо этого они должны рассматриваться скорее как спецификации или проверки работоспособности. Если тесты прерываются, они могут не указывать на неправильность кода. Например:
- Если интеграционный тест прерывается, может быть проблема с некоторым требованием, которое у вас есть, и вам необходимо пересмотреть требование, удалить, заменить или изменить тест.
- Если тест производительности будет прерван, в зависимости от того, как он был реализован, стохастическая природа этого теста может заставить вас думать, что в этом случае он просто медленно работает.
Единственное, что нужно иметь в виду, - это организовать тесты так, чтобы их было легко различить и найти.
Вам нужно постоянно писать тесты?
Бывают ситуации, когда можно пропустить тестовые случаи, потому что проверка с помощью ручного дымового тестирования просто сделать проще и не займет много времени. В этом смысле ручная проверка дыма - это действие, при котором вы запускаете свое приложение, чтобы проверить функциональность самостоятельно или кого-то еще, кто не кодировал ваши вещи. То есть, если вы собираетесь написать автоматический тест all из следующих:
- слишком сложный и запутанный
- займет много вашего рабочего времени, чтобы написать
- нет готового и простого в использовании фреймворка для тестирования
- не даст большой отдачи, например, мало шансов на регрессию
- можно сделать вручную с гораздо меньшими усилиями, чем написание автоматизированного теста
… затем напишите его и протестируйте как ручной тестовый пример. Это не стоит, если написание контрольного примера займет несколько дней, а ручное тестирование займет всего минуту.