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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

презентации превосходное введение к полностью yummy испытанию благости влечь за собой.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

вы можете узнать введение в разработку с тестовым приводом (TDD) или книга Кента Бека Развитие Управляемое Испытанием: Примером.

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

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

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

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

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

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

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

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

использовать Testivus. Все, что вам нужно знать, прямо там:)

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

xUnit, Нанит, mbUnit, etc. инструменты, которые помогут вам в написании тестов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Написание Тестируемого JavaScript - https://www.youtube.com/watch?v=OzjogCFO4Zo

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

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

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

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

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

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

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