Почему это - лучшая практика к всегда модульному тесту самая маленькая единица кода? Я нахожу, что те тесты никогда не будут переживать рефакторинг
Я использовал DBUnit, чтобы взять снимки записей в базе данных и сохранить их в формате XML. Затем мои модульные тесты (мы назвали их интеграционными тестами, когда они потребовали базы данных), может вытереть и восстановить от XML-файла в начале каждого теста.
я не уверен, стоит ли это усилия. Одной проблемой являются зависимости от других таблиц. Мы встали из-за одних только статических ссылочных столов и создали некоторые инструменты, чтобы обнаружить и извлечь все дочерние таблицы наряду с требуемыми записями. Я прочитал чью-то рекомендацию отключить все внешние ключи в Вашей базе данных интеграционного теста. Это сделало бы это путем легче подготовить данные, но Вы больше не проверяете ни на какие проблемы ссылочной целостности в своих тестах.
Другой проблемой являются изменения схемы базы данных. Мы записали некоторые инструменты, которые добавят значения по умолчанию для столбцов, которые были добавлены, так как снимки были взяты.
, Очевидно, эти тесты были путь медленнее , чем чистые модульные тесты.
, Когда Вы пытаетесь протестировать некоторый унаследованный код, где очень трудно записать модульные тесты на отдельные классы, этот подход может стоить усилия.
6 ответов
Я обнаружил то же самое, но я думаю, что важно различать частные единицы кода и общедоступные единицы кода. Я действительно думаю, что важно всегда проводить модульное тестирование «минимально возможной, пригодной для использования единицы кода, представленной в общедоступном API».
Общедоступный API не должен изменяться во время рефакторинга (поскольку он нарушает двоичную совместимость и управление версиями), поэтому это проблема действительно существует.
Что касается частного API, здесь есть баланс. Чем меньше вы тестируете, тем больше вы можете полагаться на свои тесты. Чем выше уровень ваших тестов, тем более гибкими они становятся и тем выше вероятность, что они выдержат рефакторинг.
При этом я считаю, что оба важны. Крупномасштабный рефакторинг всегда требует переделки тестов - это '
Это проблема детализации, как Златовласка и три медведя. Вам нужно что-то не слишком маленькое, не слишком большое, но самое подходящее.
Если степень детализации слишком мала, вы, возможно, сочли это пустой тратой времени. Если он слишком велик, то могут быть пропущены важные ограничения, которые должны оставаться постоянными при рефакторинге / реконфигурации и т. Д.
Как и любой «передовой опыт», эти идеи часто разрабатываются теоретически, но требуют некоторого здравого смысла и адаптации к вашей конкретной ситуации. быть полезным для вас.
Мне кажется, что чем меньше тестируемая единица кода, тем больше информации вы получите при неудачных тестах. Если у вас есть тест более высокого уровня, который охватывает более крупный фрагмент кода, то сбой меньше расскажет вам о том, в чем проблема.
В большинстве случаев я тестирую только общедоступные классы и методы. Потому что я думаю, что, как вы сказали, частные члены слишком изменчивы и подвержены изменениям.
Модификация частных и внутренних членов указывает на то, что вы меняете внутренний алгоритм, тогда как модификация публичных членов указывает на семантическую модификацию. Если я думаю, что изменение частного члена изменяет семантику моего класса, тогда, возможно, этот член не должен быть частным в конце концов.
Ошибка, появившаяся во время рефакторинга внутреннего алгоритма вашего класса, ломается в 90% случаев тесты на семантическом уровне, и в большинстве случаев, если вы тестируете часто и рано, ошибка обнаруживается быстро.
Я больше придерживаюсь подхода BDD, в результате чего я не тестирую функциональность, а результаты. При этом вы все еще тестируете функциональность, но измеряете ее ожидаемыми результатами. Я считаю, что это делает ваш тест более значимым, менее хрупким, более применимым, и в конечном итоге я пишу их меньше.
Не похоже, что вы делаете правду Разработка через тестирование , который требует итеративного цикла написания теста для небольшой части функциональности, создания функциональности, удовлетворяющей тесту, а затем рефакторинга, чтобы удалить любое дублирование, которое могло быть добавлено тестом / кодом. Похоже, вы тестируете постфактум («код всегда меняется настолько существенно, что небольшие модульные тесты просто выбрасываются»). Если тест является спецификацией функциональности (как в TDD), рефакторинг никогда не приведет к тому, что тест «не выживет».
Итак, предполагая, что вы на самом деле не выполняете TDD, вы пытаетесь найти компромисс между сколько тестового кода написать по сравнению с тем, сколько времени потратить на разработку рабочего кода. Я бы сказал, напишите достаточно тестового кода, чтобы вы знали, что ваш код делает то, что должен делать. Если вы можете сделать это с помощью более грубых тестов, это нормально, хотя, как говорили другие, это усложняет определение причин сбоя.
Тестирование - это не только рефакторинг. Его знать, когда вы закончите. Так вы можете добавлять новые функции с уверенностью, что не сломаете старые. Это значит, что после того, как вы давно ушли, кто-то другой может войти и понять ваш код, изменить его и убедиться, что он работает.
Я действительно рекомендую вам следовать практике TDD, описанной Кентом Беком . Лучше писать тесты постфактум, чем ничего не делать, но я считаю, что это гораздо менее продуктивная практика, чем TDD.
и будьте уверены, что это работает.Я действительно рекомендую вам следовать практике TDD, описанной Кентом Беком . Лучше писать тесты постфактум, чем ничего не делать, но я считаю, что это гораздо менее продуктивная практика, чем TDD.
и будьте уверены, что это работает.Я действительно рекомендую вам следовать практике TDD, описанной Кентом Беком . Лучше писать тесты постфактум, чем ничего не делать, но я считаю, что это гораздо менее продуктивная практика, чем TDD.