Comments 6
Приемочные тесты во многих случаях могут заменить юнит-тесты. Протестируй поведение системы целиком и тебе уже не обязательно тестировать каждый метод в отдельности.
Более того. Часто для возможности запуска юнит-тестов приходится изменять архитектуру: вводить доп. слои, заменить слой сервисов на тестовый. К примеру, взаимодействие с внешней системой заменяют моками. Иногда удается избежать таких усложнений, запустив набор тестов на самом верхнем уровне, который работает с реальной системой.
Более того. Часто для возможности запуска юнит-тестов приходится изменять архитектуру: вводить доп. слои, заменить слой сервисов на тестовый. К примеру, взаимодействие с внешней системой заменяют моками. Иногда удается избежать таких усложнений, запустив набор тестов на самом верхнем уровне, который работает с реальной системой.
Не согласен. И я думаю, что многие с Вами не согласятся. Приёмочные тесты могут длиться несколько часов. Что делает их непригодными для рефакторинга, например.
Возникает вопрос — а почему приемочные тесты длятся несколько часов? Обычно это происходит потому, тестируют приложение через UI, сверху донизу, через все слои. В тестирование вовлекаются медленные ресурсы (SQL DB, внешние сервисы, файловая система) — именно поэтому они и становятся долгими, и к тому же хрупкими и ненадежными. Требуется уйма дополнительных усилий на подготовку данных перед запуском теста и чистку данных после запуска. Чистить в том числе нужно и после неудачных запусков.
Подход, который предлагает Хенрик, и который мы применяли в своих проектах — организовывать приемочные тесты таким образом, чтобы они по-прежнему охватывали максимальное количество слоев, но при этом не зависели от медленных ресурсов. Если вы подмените настойщую SQL DB на In-Memory DB, файловую систему и внешние сервисы на мок, то ваши приемочные тесты станут интеграционными, и бегать будут как из пулемета.
Подход, который предлагает Хенрик, и который мы применяли в своих проектах — организовывать приемочные тесты таким образом, чтобы они по-прежнему охватывали максимальное количество слоев, но при этом не зависели от медленных ресурсов. Если вы подмените настойщую SQL DB на In-Memory DB, файловую систему и внешние сервисы на мок, то ваши приемочные тесты станут интеграционными, и бегать будут как из пулемета.
Приемочные тесты, на мой взгляд, гораздо ценнее юнит тестов. Они несут больше информации о системе в целом, часто описывают сценарии с точки зрения пользователя а не разработчика и позволяют избегать сложной настройки моков. Это так.
С другой стороны, юнит тесты очень сильно помогают выстроить дизайн приложения, когда он неизвестен (разработка через тестирование).
Сложность, связанная с изменением архитектуры для запуска юнит тестов вызвана именно тем, что тесты пишутся после того, как дизайн системы уже построен. Если делать наоборот, то есть создавать систему одновременно с тестами, то дизайн сразу растет тестируемым и подстраивать его под тесты уже не приходится.
Я думаю что нужны и те и другие тесты. Но их ценность меняется в процессе работы над проектом. Ценность юнит тестов высока сначала и постепенно снижается к концу проекта, потому что как правило мало что меняется.
Тесты, которые запускаются на самом верхнем уровне, на мой взгляд, легко писать но очень сложно поддерживать. Поэтому Хенрик предлагает писать их так, чтобы они описывали сценарии пользователя, но при этом работали на фейкнутой системе, в которой подменяются самые нижние слои. Это сделает их быстрыми и поддерживаемыми.
С другой стороны, юнит тесты очень сильно помогают выстроить дизайн приложения, когда он неизвестен (разработка через тестирование).
Сложность, связанная с изменением архитектуры для запуска юнит тестов вызвана именно тем, что тесты пишутся после того, как дизайн системы уже построен. Если делать наоборот, то есть создавать систему одновременно с тестами, то дизайн сразу растет тестируемым и подстраивать его под тесты уже не приходится.
Я думаю что нужны и те и другие тесты. Но их ценность меняется в процессе работы над проектом. Ценность юнит тестов высока сначала и постепенно снижается к концу проекта, потому что как правило мало что меняется.
Тесты, которые запускаются на самом верхнем уровне, на мой взгляд, легко писать но очень сложно поддерживать. Поэтому Хенрик предлагает писать их так, чтобы они описывали сценарии пользователя, но при этом работали на фейкнутой системе, в которой подменяются самые нижние слои. Это сделает их быстрыми и поддерживаемыми.
Только JUnit, только хардкор!
А для C# есть аналог Web Whiteboard?
Sign up to leave a comment.
Перевод статьи Хенрика Книберга «ATDD from Trenches» (ATDD с передовой)