Что такое юнит-тестирование?

Question

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

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

Answer 1

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

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

Answer 2

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

Часть имени Unit предназначена для тестирования небольших блоков кода (например, одного метода) за один раз.

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

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

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

Answer 3

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

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

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

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

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

Answer 4

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

Answer 5

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

Answer 6

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

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

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

Answer 7

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

---

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

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

JS Unit Testing (очень хорошо) - https://www.youtube.com/watch?v=-IYqgx8JxlU

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

---

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

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

---

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

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

---

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

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

Answer 8

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

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

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

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

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

Answer 9

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

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

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

Answer 10

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