Вывод юнит-тестирования на следующий уровень

Question

За прошедший год или около того я разрабатывал свои тесты TDD, так что теперь я довольно хорошо разбираюсь в основах - сначала пишу тесты, моделирую фреймворки, тестирую как можно меньше вещей, DI и т. Д.

Однако я чувствую, что есть еще много вещей, которые я не выхожу из модульного тестирования.

Например, я часто нахожу, что модульное тестирование таким образом на самом деле не проверяет интеграцию и общую большую картину того, что должен делать мой код. После всего этого я теряю из виду, дают ли тестируемые методы результаты, которые мне действительно нужны , а не только результаты, которые, как они говорят, дадут. Когда я начинаю двигаться в направлении BDD, я обнаруживаю, что эта проблема только усугубляется, что приводит к потере времени на разработку и неэффективным тестам.

Другая проблема состоит в том, что модульные тесты требуют большого объема обслуживания, чтобы поддерживать их в порядке, замедляя рефакторинг.

Когда я впервые начал модульное тестирование, как и большинство людей, я обнаружил, что то, что я писал, было действительно интеграционными тестами. Однако у этих тестов было много преимуществ - они были намного проще для чтения и служили достойной документацией по API моих программ. Они также имели тенденцию обнаруживать проблемы реального мира гораздо быстрее, нежели модульные тесты, которые, как я считаю, тратят много времени на целевые случаи, которые могут возникнуть только при неправильном использовании API (например, нулевые ссылки, деление на 0 и т. Д.).

Что вы думаете? Можете ли вы порекомендовать хорошие книги, статьи или методики, которые касаются более продвинутого модульного тестирования и поддержания производительности и эффективности?

РЕДАКТИРОВАТЬ: Просто немного следуйте за вопросами, учитывая ответы: Итак, в основном вы говорите, что несмотря на то, что я выполняю весь этот «тестовый» модуль, я не буду тестировать код… на что я отвечаю: «Но я хочу проверить код черта! Фактически, когда я написал множество «более тяжелых» интеграционных тестов, я обнаружил, что мой код имеет тенденцию быстрее достигать состояния корректности, и ошибки были выявлены гораздо раньше. Можно ли добиться этого без проблем с ремонтопригодностью интеграционных тестов?

Answer 1

TDD и BDD не означают , означающие , чтобы быть инструментами для измерения качества кода, они предназначены для того, чтобы помочь в разработке слабосвязанных, легко обслуживаемых фрагментов кода. Это больше связано с дизайном API, чем с чем-либо еще. Он предназначен для того, чтобы гарантировать, что код выполняет то, что говорит, и делает так, чтобы изменение одной части кода не влияло на другие части.

Я бы ожидал, что ваше чувство раздражения от BDD проистекает из того, что вы пишете инструменты, которые просто «устраняют ошибки» или «заменяют ваш процесс контроля качества», и то, и другое не предназначены ни для BDD, ни для TDD. Разработка, управляемая тестами, означает «разработка, управляемая тестами», а не «тесты, управляемые разработкой». Мне кажется, что вы хотите последнее.

Интеграционное тестирование и обеспечение качества программного обеспечения - это совершенно разные темы, но я понимаю причины, стоящие за огромной путаницей между ними и связыванием TDD с ними.

Разработка, управляемая тестами, означает «разработка, управляемая тестами», а не «тесты, управляемые разработкой». Мне кажется, что вы хотите последнее.

Обновление Просто хочу поделиться своей записью в блоге по этой проблеме: Повторяйте за мной: разработка через тестирование - это дизайн, а НЕ тестирование!

Answer 2

Я на той же дороге, что и ты, кажется. Для меня книга, которая стала моей Библией модульного тестирования: xUnit Test Patterns - Refactoring Test Code by Gerard Meszaros.

Answer 3

Модульное тестирование - это только один тип тестирования, это не единственный тип тестирования.

Модульное тестирование должно охватывать наименьшую возможную единицу работы, макетирование всех зависимостей является очень важным процессом для достижения этой цели, поскольку эти зависимости имеют свои собственные модульные тесты, которые их покрывают.

После того, как вы покрыли приличное количество ваших маленьких юнитов, вы делаете то, что называется Функциональный тест , который выглядит как юнит-тест, однако он не высмеивает все, что вы издеваетесь в юнит-тесте Как правило, если ваша система построена другими командами, функциональные тесты проверяют только зависимости, введенные другими командами, но код вашей команды не проверяется.

После того, как вы пройдете функциональный тест, у вас будут Интеграционные тесты , и здесь, когда вы начнете использовать реальные зависимости от других команд, в общем, у вас не должно быть насмешек в такого рода тестах.

Учитывая тот факт, что все три типа тестов построены с использованием mstest или NUnit, это все еще тест кода.

Answer 4

Посмотрите "Построение объектно-ориентированного программного обеспечения" Бертрана Майера.

Концепция называется «Контрактно-ориентированная разработка». Это встроенный тип тестирования на функциональном уровне, он изменил способ программирования.

Если вы используете CDD в Eiffel, языке, также написанном Bertrand, они автоматически проверяются средой выполнения во время фазы тестирования и отладки.

http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136291554

http://dev.eiffel.com

Answer 5

Если вы действительно следуете TDD, как описано практиками, каждый тест должен проверять относительно небольшую часть вашего кода (всего несколько строк). По определению, это не интеграционные тесты. Сотрудники TDD скажут вам, что вам нужен целый отдельный набор тестов для проведения интеграционного тестирования.

Вы правы в том, что такой набор тестов TDD может в конечном итоге застопорить вас в мелочах. Разработка, основанная на тестировании, по определению - это создание, проектирование и тестирование деревьев, а не лесов. TDD - это создание требований с помощью модульных тестов, но по своей природе оно воплощает требования на микроскопическом уровне.

Если, как утверждают сотрудники TDD, вам нужны отдельные интеграционные тесты, то вам также нужны требования, спецификации и процедуры для этих тестов. Когда вы начинаете подниматься по пищевой цепочке, ваши тесты становятся все более сложными, пока вы не достигнете уровня функционального / пользовательского интерфейса, где автоматическое тестирование становится практически невозможным.