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

Я видел много вопросов, спрашивая, «как» модульное тестирование на конкретном языке, но не вопрос не спрашивая «что», «почему», а «когда».

* Что это?
* Что она делает для меня?
* Почему я должен использовать?
* Когда я должен использовать его (в том числе, когда нет)?
* Каковы некоторые распространенные ошибки и заблуждения

 

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

* Запуск тестов становится автоматизирует-способным и повторяемость
* Вы можете проверить на гораздо более детальном уровне, чем точку и нажмите тестирование с помощью графического интерфейса

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

Другой способ смотреть на модульного тестирования является то, что вы пишете тесты в первую очередь. Это известно как тест-Driven Development (TDD для краткости). TDD приносит дополнительные преимущества:

* Вы не пишите спекулятивным «Я, возможно, потребуется это в будущем» код - просто достаточно, чтобы сделать тесты пройдены
* Код, который вы написали, всегда покрыт тестами
* При написании теста первого, вы вынуждены думать о том, как вы хотите назвать код, который обычно улучшает дизайн кода в долгосрочной перспективе.

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

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

---

Edit: Один заблуждения приходит на ум, хотя я не уверен, если это так часто. Я слышал, менеджер проекта говорит, что модульные тесты из команды написать весь код дважды. Если она выглядит и чувствует, что путь, хорошо, вы делаете это неправильно. Мало того, что писать тесты обычно ускорить развитие, но это также дает вам удобный «теперь я сделал» показатель того, что вы не имели бы в противном случае.

 

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

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

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

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

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

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

Наибольшая ловушкой является то , что разработчики тестирование слишком большой блока, или они считают метод единичными. Это особенно верно , если вы не понимаете , [Инверсия управления](https://en.wikipedia.org/wiki/Inversion_of_control) - в этом случае ваши юнит - тесты всегда превратится в интеграции тестирования конца до конца. Юнит - тестирование должно проверить индивидуальное поведение - и большинство методов имеют много поведения.

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

 

Основное отличие модульного тестирования, в отличии от «просто открыть новый проект и проверить этот конкретный код» является то , что он *автоматизирован* , таким образом , *повторяемым* .

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

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

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

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

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

 

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

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

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

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

 

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

1. TDD не значит писать в два раза больше кода. Тест-код, как правило, довольно быстро и безболезненно писать и является ключевой частью вашего процесса разработки и критически.
2. TDD поможет вам понять, когда прекратить кодирование! Ваши тесты дают вам уверенность, что вы сделали достаточно для теперь и может остановить настройки и перейти на следующую вещь.
3. Тесты и работа коды вместе, чтобы достичь лучшего кода. Ваш код может быть плохим / багги. Ваш тест может быть плохим / багги. В TDD вы ставку на шансы ОБА быть плохим / багги будучи довольно низким. Часто его тест, который нуждается в фиксации, но это еще хороший результат.
4. TDD помогает при кодировании запоров. Вы знаете, что чувство, что у вас есть так много, чтобы вы едва знаете, с чего начать? Это пятницу во второй половине дня, если вы просто откладывайте в течение пары часов больше ... TDD позволяет конкретизировать очень быстро, что вы думаете, что вам нужно сделать, и получает ваше кодирование быстро движется. Кроме того, как лабораторные крысы, я думаю, все мы ответить на этот большой зеленый свет и работать, чтобы увидеть его снова!
5. Аналогичным образом, эти типы дизайнера могут видеть то, что они работают. Они могут блуждать для сока / сигарет / iphone перерыва и вернуться к монитору, который сразу дает им визуальный сигнал о том, где они получили. TDD дает нам что-то подобное. Это легче увидеть, где мы получили, когда жизнь вмешается ...
6. Я думаю, что это был Фаулер, который сказал: «Несовершенство тесты, которыми управляют часто, гораздо лучше, чем совершенные тесты, которые никогда не написанными на всех». Я интерпретирую это как дать мне разрешение писать тесты, где я думаю, что они будут наиболее полезны, даже если остальная часть моего покрытия коды является крайне неполным.
7. TDD помогает во всех видах удивительным образом по линии. Хорошие модульные тесты могут помочь документ, что-то должен делать, они могут помочь вам перенести код из одного проекта в другой и дать вам необоснованное чувство превосходства над своими не-тестирования коллег :)

[Данная презентация](http://www.masukomi.org/talks/unit_testing_talk_2/index.xul?data=slide_data.txt#page1) представляет собой прекрасное введение всех вкуснятина влечет за собой испытание благости.

 

Я хотел бы рекомендовать XUnit Testing Patterns книгу Джерард Месарош. Это большое , но это большой ресурс на модульном тестировании. Вот ссылка на его веб - сайт , где он обсуждает основы модульного тестирования. <http://xunitpatterns.com/XUnitBasics.html>

 

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

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

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

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

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

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

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

 

Это мой взгляд на него. Я бы сказал , модульное тестирование является практикой написания программных тестов , чтобы убедиться , что ваше реальное программное обеспечение делает то , что он предназначен для. Это началось с [JUnit](http://junit.org/) в мире Java и стал передовой практикой в PHP , а также с [SimpleTest](http://simpletest.org/) и [PHPUnit](http://www.phpunit.de/) . Это ядро практика экстремального программирования и помогает вам быть уверены , что программа по- прежнему работает , как предполагалось после редактирования. Если у вас есть достаточное количество тестового покрытия, вы можете сделать основной рефакторинг, исправление ошибок или добавлять новые функции быстро с гораздо меньшим страхом введения других проблем.

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

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

Структура будет выполнять все тесты против вашего кода, а затем доложите успех или неудачу каждого теста. PHPUnit запускается из командной строки Linux по умолчанию, хотя есть HTTP интерфейсы доступны для него. SimpleTest является веб-природой и намного легче получить и работает, ИМО. В сочетании с Xdebug, PHPUnit может дать вам автоматизированную статистику для покрытия кода, который некоторые люди находят очень полезными.

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

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

 

БИБЛИОТЕКИ как [NUnit](http://en.wikipedia.org/wiki/NUnit) , [XUnit](http://en.wikipedia.org/wiki/XUnit) или [JUnit](http://en.wikipedia.org/wiki/JUnit) просто обязательным , если вы хотите , чтобы развивать свои проекты , используя [TDD](http://en.wikipedia.org/wiki/Test-driven_development) подход популяризировал Кент Бек:

Вы можете прочитать *[Введение в Test Driven Development (TDD)](http://www.agiledata.org/essays/tdd.html)* или книгу Кента Бека *[Test Driven Development: К примеру](http://rads.stackoverflow.com/amzn/click/0321146530)* .

Затем, если вы хотите быть уверены , что ваши тесты охватывают «хорошую» часть вашего кода, вы можете использовать программное обеспечение , как [NCover](http://en.wikipedia.org/wiki/NCover) , [JCover](http://www.mmsindia.com/JCover.html) , [PartCover](http://sourceforge.net/projects/partcover/) или любой другой . Они скажут вам процент покрытия кода. В зависимости от того , насколько вы искусны в TDD, вы будете знать , если вы практиковали это достаточно хорошо :)

 

Я думаю, дело в том , что вы не понимаете, что рамки модульного тестирования , как NUnit (и тому подобное) помогут вам в *автоматизации* малых и средних испытаний. Как правило , вы можете запустить тесты в GUI (что в случае с [NUnit](http://www.nunit.org/) , например), просто нажав на кнопку , а затем - с надеждой - увидеть прогресс бар остаются зелеными. Если краснеет, структура показывает , какой тест не удалось , и что именно пошло не так. В обычном тестовом модуле, вы часто используют утверждения, например , `Assert.AreEqual(expectedValue, actualValue, "some description")`- так что, если два значения не равны , вы увидите сообщение об ошибке сказав «некоторое описание ожидаемого <expectedValue> но <actualValue>».

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

 

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

[XUnit](http://en.wikipedia.org/wiki/XUnit) , [NUnit](http://en.wikipedia.org/wiki/NUnit) , [MBUnit](http://mbunit.com/) и т.д. инструменты , которые помогут вам в написании тестов.

 

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

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

XUnit там, чтобы помочь с этим тестирования - они структуры, которые помогают с этим. Часть этого автоматизирована испытание бегуны, которые говорят вам, что тест не в состоянии, и какие из них проходит.

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

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

 

Используйте [Testivus](http://www.artima.com/weblogs/viewpost.jsp?thread=203994) . Все , что вам нужно знать, прямо там :)

 

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

 

Test Driven Development имеет вида берется Тест термина единицы. Как старый таймер я буду упоминать более общее определение его.

Unit Test также означает, что тестирование одного компонента в более крупной системе. Это единственный компонент может быть DLL, EXE, библиотека классов, и т.д. Это может быть даже одна система многопоточного приложения системы. Таким образом, в конечном счете, модульное тестирование заканчивается время испытания, что вы хотите назвать одну часть более крупной системы.

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

 

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

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

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

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

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

 

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

---

Модульное тестирование: Протокол Теперь Спасет часов спустя - Эрик Манн - <https://www.youtube.com/watch?v=_UmmaPe8Bzc>

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

---

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

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

---

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

---

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

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

 

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

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

Сейчас мы до более чем 40%, и нам удалось подстрелить большинство фруктов с низким висящей.

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

 

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

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

Я не дойду до конца, потому что мне нужно-на-рутинного-теперь-Проклятье, но это было хорошее упражнением.

 

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