В чем разница между юнит-тестами и обычными тестами?

Question

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

---

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

Answer 1

«Юнит-тесты» - это тесты, такие же, как и обычные тесты.но они являются подмножеством.

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

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

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

Это больше похоже на концепцию «тщательного тестирования всего и вся».

Answer 2

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

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

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

Answer 3

При рефакторинге кода вам не нужно проверять каждый путь кода вручную. Это огромная экономия времени.

Также см. http://en.wikipedia.org/wiki/Regression_testing.

Answer 4

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

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

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