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

Модульное тестирование-это, грубо говоря, тестирование битов вашего кода в изоляции с тестовым кодом. Непосредственные преимущества, которые приходят на ум::

• Выполнение тестов становится автоматизированным и повторяемым
• Вы можете тестировать на гораздо более детальном уровне, чем point-and-click тестирование через GUI

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

Еще один способ взглянуть на модульное тестирование - это сначала написать тесты. Это называется тестовой разработкой (сокращенно TDD). TDD приносит дополнительные преимущества:

• Вы не пишете спекулятивный код "I might need this in the future" - просто достаточно, чтобы тесты прошли
• Написанный вами код всегда покрывается тестами
• Написав сначала тест, вы вынуждены думать о том, как вы хотите вызвать код, что обычно улучшает дизайн кода в долгосрочной перспективе.

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

Иногда написание модульных тестов может быть болезненным. Когда это случится, постарайтесь найти кого-нибудь, кто поможет вам, и не поддавайтесь искушению "just write the damn code". Модульное тестирование очень похоже на мытье посуды. Это не всегда приятно, но это держит вашу метафорическую кухню чистой, и вы действительно хотите, чтобы она была чистой. :)

Edit: на ум приходит одно заблуждение, хотя я не уверен, что оно настолько распространено. Я слышал, как руководитель проекта говорил, что модульные тесты заставляют команду писать весь код дважды. Если это выглядит и чувствует себя так, что ж, вы делаете это неправильно. Написание тестов обычно не только ускоряет разработку, но и дает Вам удобный индикатор "now I'm done", которого у вас не было бы в противном случае.

Я не спорю с Дэном (хотя лучшим выбором может быть просто не отвечать)...но...

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

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

1. Облегчите изменение технической реализации, убедившись, что вы не меняете поведение (рефакторинг). Правильно протестированный модульный код может быть агрессивно рефакторизован/очищен с небольшим шансом сломать что-либо, не заметив этого.
2. Дайте разработчикам уверенность при добавлении поведения или внесении исправлений.
3. Документируйте свой код
4. Укажите области вашего кода, которые тесно связаны. Трудно создать модульный тестовый код, который был бы тесно связан
5. Предоставьте средство для использования вашего API и ищите трудности на ранней стадии
6. Указывает на методы и классы, которые не очень связны

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

Я бы посоветовал вам использовать его для любой системы или части системы, которая моделирует реальное поведение. Другими словами, он особенно хорошо подходит для развития предпринимательства. Я бы не стал использовать его для throw-away/utility программ. Я бы не стал использовать его для частей системы, которые проблематично тестировать (UI-распространенный пример, но это не всегда так)

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

Самое большое заблуждение заключается в том, что программисты не должны тестировать. Только плохие или ленивые программисты верят в это. Стоит ли парню, строящему вашу крышу, не испытывать ее? Должен ли врач, заменяющий сердечный клапан, не проверять новый клапан? Только программист может проверить, что его код делает то, что он намеревался сделать (QA может проверить крайние случаи-как код ведет себя, когда ему говорят делать то, что программист не собирался, и клиент может сделать приемочный тест - делает ли код то, что клиент заплатил за него)

Основное отличие модульного тестирования, в отличие от "just opening a new project and test this specific code", заключается в том , что оно автоматизировано и поэтому повторяется .

Если вы протестируете свой код вручную, это может убедить вас в том, что код работает идеально - в его текущем состоянии . Но как насчет недели спустя, когда вы внесли в него небольшие изменения? Готовы ли вы повторно протестировать его вручную, когда что- нибудь изменится в вашем коде? Скорее всего нет :-(

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

Это главное преимущество модульных тестов перед ручным тестированием. Но подождите, есть еще кое-что:

• модульные тесты значительно сокращают цикл обратной связи разработки : при наличии отдельного отдела тестирования вам может потребоваться несколько недель, чтобы узнать, что в вашем коде есть ошибка, к этому времени вы уже забыли большую часть контекста, поэтому вам может потребоваться несколько часов, чтобы найти и исправить ошибку; OTOH с модульными тестами цикл обратной связи измеряется в секундах, и процесс исправления ошибки обычно идет по принципу " о sh*t, я забыл проверить это условие здесь" :-)
• модульные тесты эффективно документируют (ваше понимание) поведение вашего кода
• модульное тестирование заставляет вас пересмотреть свой выбор дизайна, что приводит к более простому и чистому дизайну

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

Меня никогда не учили модульному тестированию в университете, и мне потребовалось некоторое время, чтобы это сделать. Я прочитал об этом, сказал: "Ах, да, автоматическое тестирование, это может быть круто, я думаю", а потом я забыл об этом.

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

А теперь у вас есть проблема: сломанный код находится в багажнике, и никто даже не знает. В лучшем случае внутренний тестер находит его до того, как вы отправите, но исправление кода, которое происходит в конце игры, стоит дорого. И если ни один внутренний тестер не найдет it...well, это может стать очень дорогим.

Решение - это модульные тесты. Они будут ловить проблемы, когда вы пишете код - что прекрасно, - но вы могли бы сделать это вручную. Реальная выгода заключается в том, что они будут ловить проблемы через девять месяцев, когда вы сейчас работаете над совершенно другим проектом, но летний стажер думает, что это будет выглядеть более опрятно, если эти параметры были в алфавитном порядке, а затем модульный тест, который вы написали в прошлом, терпит неудачу, и кто - то бросает вещи в стажера, пока он не изменит порядок параметров обратно. Это и есть "why" модульных тестов. :-)

Скинувшись на философские плюсы юнит-тестирования и TDD вот несколько ключевых "lightbulb" наблюдений, которые поразили меня на моих предварительных первых шагах на пути к TDD просветлению (ни одного оригинального или обязательно новостного)...

1. TDD означает, что NOT означает написание вдвое большего количества кода. Тестовый код, как правило, довольно быстро и безболезненно пишется и является ключевой частью вашего процесса проектирования и критически важен.

2. TDD помогает вам понять, когда нужно прекратить кодирование! Ваши тесты дают вам уверенность в том, что вы уже достаточно сделали на данный момент и можете прекратить настройку и перейти к следующему шагу.

3. Тесты и код работают вместе, чтобы добиться лучшего кода. Ваш код может быть плохим / глючным. Ваш TEST может быть плохим / глючным. В TDD вы делаете ставку на то, что шансы BOTH быть плохим / багги довольно низки. Часто Это тест, который нуждается в исправлении, но это все еще хороший результат.

4. TDD помогает при кодировании запоров. Вы знаете это чувство, что у вас так много дел, что вы едва знаете, с чего начать? Сегодня пятница после обеда,если вы просто потянете еще пару часов... TDD позволяет вам очень быстро конкретизировать то, что вы думаете, что вам нужно сделать, и быстро продвигает ваше кодирование. Кроме того, как лабораторные крысы, я думаю, что мы все реагируем на этот большой зеленый свет и усердно работаем, чтобы увидеть его снова!

5. В аналогичном ключе эти дизайнерские типы могут SEE то, над чем они работают. Они могут отвлечься на перерыв сока / сигареты / iphone и вернуться к монитору, который немедленно дает им визуальный сигнал о том, куда они попали. TDD дает нам нечто подобное. Легче понять, куда мы попали, Когда вмешивается жизнь...

6. Я думаю, что именно Фаулер сказал:"несовершенные тесты, выполняемые часто, намного лучше, чем совершенные тесты, которые никогда не пишутся вообще". Я интерпретирую это как разрешение мне писать тесты там, где я думаю, что они будут наиболее полезны, даже если rest моего покрытия кода является прискорбно неполным.

7. TDD помогает во всех видах удивительных способов вниз по линии. Хорошие модульные тесты могут помочь документировать то, что должно быть сделано, они могут помочь вам перенести код из одного проекта в другой и дать вам неоправданное чувство превосходства над вашими не тестирующими коллегами :)

Эта презентация является отличным введением во все вкуснятины, которые влечет за собой тестирование благости.

Я хотел бы порекомендовать вам книгу xUnit Testing Patterns от Gerard Meszaros. Это большой, но отличный ресурс для модульного тестирования. Вот ссылка на его веб-сайт, где он обсуждает основы модульного тестирования. http://xunitpatterns.com/XUnitBasics.html

Я использую модульные тесты, чтобы сэкономить время.

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

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

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

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

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

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

LibrarIES как NUnit, xUnit или JUnit просто обязательны, если вы хотите развивать свои проекты, используя подход TDD , популяризированный Кентом Беком:

Вы можете прочитать введение в разработку на основе тестов (TDD) или книгу Кента Бека " разработка на основе тестов: на примере ".

Затем, если вы хотите быть уверены, что ваши тесты охватывают "good" часть вашего кода , Вы можете использовать программное обеспечение , такое как NCover, JCover, PartCover или любое другое. Они сообщат вам процент покрытия вашего кода. В зависимости от того, насколько вы искусны в TDD, вы будете знать, достаточно ли хорошо вы его практиковали :)

Вот мое мнение на этот счет. Я бы сказал, что модульное тестирование-это практика написания тестов программного обеспечения для проверки того, что ваше реальное программное обеспечение делает то, что должно. Это началось с jUnit в мире Java и стало лучшей практикой в PHP, а также с SimpleTest и phpUnit . Это основная практика экстремального программирования и помогает вам быть уверенным, что ваше программное обеспечение все еще работает так, как задумано после редактирования. Если у вас достаточно тестового покрытия, вы можете сделать крупный рефакторинг, исправить ошибки или быстро добавить функции, не опасаясь появления других проблем.

Это наиболее эффективно, когда все модульные тесты могут быть запущены автоматически.

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

Платформа будет выполнять все тесты против вашего кода, а затем сообщать об успехе или неудаче каждого теста. phpUnit запускается из командной строки Linux по умолчанию, хотя для него доступны интерфейсы HTTP. SimpleTest по своей природе является веб-сайтом, и его гораздо легче запустить, IMO. В сочетании с xDebug, phpUnit может дать вам автоматизированную статистику покрытия кода, которую некоторые люди считают очень полезной.

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

Это хорошая практика, чтобы сохранить ваши модульные тесты в том же хранилище, как приложения.

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

Единичная часть имени связана с намерением тестировать небольшие единицы кода (например, один метод) за один раз.

xUnit есть, чтобы помочь с этим тестированием - они являются фреймворками, которые помогают в этом. Часть этого-автоматизированные тестовые бегуны, которые говорят вам, какой тест не прошел, а какой-нет.

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

Вы можете иметь тест, чтобы проверить, что ожидаемое исключение было брошено, без необходимости писать весь блок try catch самостоятельно.

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

xUnit , NUnit, mbUnit и т.д. это инструменты, которые помогут вам в написании тестов.

Я думаю, что вы не понимаете, что фреймворки модульного тестирования, такие как NUnit (и тому подобное), помогут вам автоматизировать небольшие и средние тесты. Обычно вы можете запустить тесты в GUI (например , в случае с NUnit), просто нажав кнопку, а затем - надеюсь - увидеть, что индикатор выполнения остается зеленым. Если он станет красным, фреймворк покажет вам, какой тест не удался и что именно пошло не так. В обычном модульном тесте вы часто используете утверждения, например Assert.AreEqual(expectedValue, actualValue, "some description") -таким образом, если два значения неравны, вы увидите ошибку, говорящую "некоторое описание: ожидалось <expectedValue>, но было <actualValue>".

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

Модульное тестирование - это тестирование единицы кода (например, одной функции) без необходимости в инфраструктуре, на которую опирается эта единица кода. т. е. испытайте его в изоляции.

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

Таким образом, модульный тест будет осуществлять функциональность, заключенную в тестируемом "function", без побочных эффектов обновления базы данных.

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

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

Используйте Тестивус . Все, что вам нужно знать, находится прямо здесь :)

Прежде всего, идет ли речь о модульном тестировании или о каких-либо других видах автоматизированного тестирования (интеграция, нагрузка, UI тестирование и т.д.).), ключевое отличие от того, что вы предлагаете, заключается в том, что он автоматизирован, воспроизводим и не требует использования каких-либо человеческих ресурсов (= никто не должен выполнять тесты, они обычно выполняются одним нажатием кнопки).

Разработка на основе тестов в некотором роде взяла на себя термин юнит-тест. Как старожил я упомяну более общее определение этого понятия.

Модульный тест также означает тестирование одного компонента в более крупной системе. Этот единственный компонент может быть dll, exe, библиотекой классов и т. д. Это может быть даже одна система в мультисистемном приложении. Таким образом, в конечном счете модульный тест оказывается тестированием всего, что вы хотите назвать отдельной частью более крупной системы.

Затем вы перейдете к интегрированному или системному тестированию, проверив, как все компоненты работают вместе.

Я пошел на презентацию по модульному тестированию в FoxForward 2007, и мне сказали никогда не тестировать ничего, что работает с данными. В конце концов, если вы тестируете на живых данных, результаты непредсказуемы, и если вы не тестируете на живых данных, вы на самом деле не тестируете код, который вы написали. К сожалению, это большая часть кодирования, которое я делаю в эти дни. :-)

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

Я не дошел до конца, потому что мне было 27, но это было хорошее упражнение.

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

Как же тогда мы можем провести модульное тестирование?

Вы начинаете с малого. Проект, в который я только что вошел, не имел модульного тестирования еще несколько месяцев назад. Когда покрытие было настолько низким, мы просто выбирали файл, который не имел покрытия, и нажимали "add tests".

Прямо сейчас мы дошли до более чем 27, и нам удалось сорвать большую часть низко висящих фруктов.

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

Это объясняет, почему вы должны проводить модульное тестирование.

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

Модульное Тестирование: Минуты Сейчас Сэкономят Часы Позже-Эрик Манн- https://www.youtube.com/watch?в=_UmmaPe8Bzc

Модульное тестирование JS (очень хорошо) - https://www.youtube.com/watch?в=-IYqgx8JxlU

Половина JavaScript - https://www.youtube.com/watch?в=OzjogCFO4Zo

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

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

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

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

Это довольно запутанно, когда вы впервые слышите об этом предмете и думаете про себя: разве я уже не тестирую свой код? И код, который вы написали, работает так, как он уже должен работать, "why do I need another framework?"... Да, вы уже тестируете свой код, но компьютер лучше справляется с этим. Вам просто нужно написать достаточно хорошие тесты для функции/единицы кода один раз, и о rest позаботится могучий cpu вместо того, чтобы вручную проверять, что весь ваш код все еще работает, когда вы вносите изменения в свой код.

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

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