Меня никогда не учили юнит-тестированию в университете, и мне потребовалось некоторое время, чтобы "получить" его. Я прочитал об этом, пошел «ах, правильно, автоматическое тестирование, это может быть круто, я думаю», а потом я забыл об этом.
Прошло немного больше времени, прежде чем я действительно понял вопрос: допустим, вы работаете в большой системе и пишете небольшой модуль. Он компилируется, вы проходите его темпами, он прекрасно работает, вы переходите к следующей задаче. Девять месяцев спустя и две версии спустя кто-то другой вносит изменения в какую-то , казалось бы, несвязанную часть программы, и это ломает модуль. Хуже того, они проверяют свои изменения, и их код работает, но они не проверяют ваш модуль; черт, они могут даже не знать, что ваш модуль существует .
А теперь у вас проблема: сломанный код находится в багажнике, и никто даже не знает. В лучшем случае внутренний тестер находит его перед отправкой, но исправление кода в конце игры стоит дорого. И если никакой внутренний тестер не найдет его ... ну, это действительно может стать очень дорогим.
Решение - модульные тесты. Они поймают проблемы, когда вы напишите код - и это нормально - но вы могли бы сделать это вручную. Реальная выгода в том, что они поймают проблемы через девять месяцев, когда вы сейчас работаете над совершенно другим проектом, но летний стажер думает, что это будет выглядеть более аккуратно, если бы эти параметры были в алфавитном порядке - и затем модульный тест Вы написали, что обратный путь не удался, и кто-то бросает вещи в стажера, пока он не изменит порядок параметров обратно. Это «почему» модульных тестов. : -)