Модульное тестирование - не может перейти от теории к практике

Question

Кажется, что каждый пример модульного теста, с которым я столкнулся, невероятно очевиден и консервирован. Такие вещи, как утверждают, что х + 3 == 8, и еще много чего. Мне просто трудно понять, как я буду тестировать объекты реального мира, такие как запросы SQL, или работает ли regEx, используемый для проверки формы, правильно.

Показательный пример: я работаю над двумя сайтами ASP.NET MVC 2, которые управляются БД. У меня есть тестовое решение для каждого из них, но я не знаю, какие тесты будут полезны. Большая часть работы сайта - запись данных или извлечение и организация данных из БД. Буду ли я просто проверять, чтобы различные запросы успешно обращались к БД? Как мне проверить правильность (например, данные, записываемые в соответствующие поля, или правильные данные, извлекаемые)?

Мне просто трудно преобразовать свой собственный неформальный способ тестирования и отладки в более формализованный, assert (x) вид тестирования.

Answer 1

Чтобы модульное тестирование было осуществимо, ваш код должен будет соответствовать принципам связности и развязки.Фактически, это будет навязывать эти принципы вашему коду по мере его применения.Это означает, что если ваш код недостаточно хорошо продуман (т. Е. Принципы разработки ОО применены правильно), модульное тестирование будет практически невозможным и / или бесполезным.

Так что, вероятно, лучший способ подумать об этом будет«Как я могу разделить всю работу моего приложения на более мелкие, более сплоченные фрагменты кода, которые выполняют только одну или две вещи и используют их для сборки моего приложения?»

Пока вы не усвоите этот образ мышления в терминахо том, как вы думаете о своем коде, модульное тестирование, вероятно, не будет иметь смысла.

Answer 2

Во-первых, спросите себя: «Почему модульные тесты сложно написать для моего реального кода?»Возможно, ответ в том, что ваш настоящий код делает слишком много.Если у вас есть один модуль кода, заполненный операторами «new» и «if» и операторами «switch» и умными математическими операторами и доступом к базе данных, будет сложно написать один тест, не говоря уже о адекватном тестировании логики иматематикаНо если вы вытащите «новые» операторы в фабричный метод, вы легко сможете получить фиктивные объекты для тестирования.Если вы вытащите предложения «if» и «switch» в шаблоны конечных автоматов, у вас не будет столько комбинаций для тестирования.Если вы удалите доступ базы данных к объекту внешнего поставщика данных, вы можете предоставить простые тестовые данные для выполнения ваших математических операторов.Теперь вы тестируете создание объектов, переходы состояний и доступ к данным отдельно от ваших умных математических выражений.Все эти шаги стали проще благодаря их упрощению.

Ключевой код причины, который сложно проверить, состоит в том, что он содержит «внутренние зависимости», такие как создаваемые зависимости или зависимости от библиотек.Если ваш код говорит "Foo theFoo = new Foo ();"Вы не можете легко заменить MockFoo для тестирования.Но если ваш конструктор или метод запрашивает передачу theFoo, а не конструирование самого себя, ваш тестовый набор может легко пройти в MockFoo.

Когда вы пишете код, спросите себя: «Как я могу написать модульный тест дляэтот код?Если ответ «это сложно», вы можете изменить код, чтобы облегчить его тестирование.Это делает ваш модульный тест первым фактическим потребителем вашего кода - вы тестируете интерфейс к своему коду, записывая тест.

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

Юнит-тестирование - это не только тесты.Написание модульных тестов фактически улучшает ваши проекты.Пройдите немного дальше по пути, и вы получите тестовую разработку.

Удачи!

Answer 3

Ну, если x + 3 == 8 недостаточно подсказки, как насчет x == y?

Сказал иначе, что вы тестируете, так этоправильное и неправильное поведение типов или функций не только при использовании с обычными условиями, но и в непредвиденных условиях.С классом, например, вы должны признать, что просто создание экземпляра недостаточно.Выполнены ли условия класса?Что насчет постусловий?Что должно произойти, когда они не встречаются?Здесь вы устанавливаете границы между вами и человеком, использующим класс (и, конечно, вы тоже), чтобы различать ошибку в классе или ошибку в использовании класса пользователем.Изменяются ли экземпляры вашего класса при использовании с конкретными шаблонами кодирования?Если так, то как?Если нет, то почему, и (в идеале) при всех возможных условиях использования;правильно ли это поведение?
Модульные тесты также являются хорошим местом для пользователя (например) класса, чтобы увидеть, как ожидается использование класса, как его избежать и что может произойти в исключительных случаях (где, если что-то идет не так, ваш класс должен реагировать определенным образом, а не просто ломаться).Вроде как встроенная документация для разработчика.

Answer 4

Возможно, изучение на примере было бы наиболее полезным для вас. Вы можете взглянуть на пример приложения NerdDinner и посмотреть, какое тестирование оно выполняет. Вы также можете посмотреть на исходный код MVC и посмотреть, как он тестируется.