Что такое модульное тестирование, и требует ли оно написания кода?

Question

Я присоединился к новой команде, и у меня возникли проблемы с пониманием того, как они проводят юнит-тесты.Когда я спросил, где написаны модульные тесты, они объяснили, что не выполняют свои модульные тесты таким образом.

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

У меня сложилось впечатление, что модульные тесты - это код, написанный для проверки поведения в небольшом разделе кода.Например, вы можете написать модульный тест, чтобы убедиться, что он возвращает правильное значение, и сделать соответствующие вызовы в базу данных.используйте фреймворк, такой как NUnit или MbUnit, чтобы помочь вам в ваших утверждениях.

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

Может ли кто-нибудь дать разъяснения в моем или их недопонимании?*

Answer 1

Я работал в местах, которые проводили тестирование таким образом и называли это модульным тестированием. Это напомнило мне цитату, приписываемую Эйбу Линкольну:

Линкольн: Сколько ног у собаки?

Другой парень: 4.

Линкольн: Что, если мы назвали хвост ногой?

Другой парень: Ну, тогда было бы 5.

Линкольн: Нет, ответ до сих пор 4. Называть хвост ногой не значит.

Answer 2

Они объяснили, что они называют юнит-тесты, когда они на самом деле проверить код, который они написали локально, и что все пункты подключены.

Это не модульный тест. Это обзор кода. Обзоры кода хороши, но без реальных юнит-тестов все сломается.

Модульные тесты предполагают написание кода. В частности, модульное тестирование работает на одном модуле, который является просто классом или компонентом вашего программного обеспечения.

Если тестируемый класс зависит от другого класса, и вы тестируете оба класса вместе, у вас есть интеграционный тест. Интеграционные тесты хороши. В зависимости от языка / среды вы можете использовать одну и ту же среду тестирования (например, junit для Java) как для модульных, так и для интеграционных тестов. Если у вас есть зависимость, но вы имитируете или заглушаете эту зависимость, тогда у вас есть чистый модульный тест.

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

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

Answer 3

Ваши товарищи по команде не проводят юнит-тестирование. Они занимаются разработкой "лети у места твоих штанов".

Answer 4

Ваши предположения верны.

Выполнение проекта без юнит-тестов (как они делают, не обманывайте себя) может показаться хорошим в первые несколько недель: меньше кода для написания, меньше архитектуры для мышленияо, меньше проблем для беспокойства.И вы можете видеть, что код работает правильно, верно?

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

Если не стоит тестировать ее (с помощью реальных юнит-тестов), то в первую очередь не стоит писать код.Это знают все, кто пробовал кодировать без модульных тестов и без них.Пожалуйста, пожалуйста, заставьте их передумать.Каждый раз, когда часть непроверенного кода проверяется где-то, щенок ужасно умирает.

Кроме того, я должен сказать, что намного (много) сложнее добавить тесты позже в проект, который был выполнен без тестирования вИмейте в виду, чем строить тестовый и производственный код с самого начала.Тестирование не только помогает вам убедиться, что ваш код работает нормально, оно улучшает качество вашего кода, заставляя вас принимать правильные решения (например, кодирование на интерфейсах, слабая связь, инверсия управления и т. Д.)

Answer 5

Если добавить два моих цента, да, это действительно не модульное тестирование.ИМХО, основные особенности юнит-тестов в том, что они должны быть быстрыми, автоматизированными и изолированными.Вы можете использовать фальшивый фреймворк, такой как RhinoMocks, чтобы изолировать внешние зависимости.

Модульные тесты также должны быть очень простыми и короткими.В идеале не более длины экрана.Это также одно из немногих мест в разработке программного обеспечения, где копирование и вставка кода могут быть лучшим решением, чем создание многократно используемых и высоко абстрактных функций.Причина, по которой простота имеет такой высокий приоритет, заключается в том, чтобы избежать проблемы «Кто следит за наблюдателями».Вы действительно не хотите быть в ситуации, когда у вас есть сложные ошибки в ваших модульных тестах, потому что они сами не тестируются.Здесь вы полагаетесь на предельную простоту и крошечный размер тестов, чтобы избежать ошибок.

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

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

Answer 6

«Модульное тестирование»! = «Модульные тесты».

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