В чем суть автотестов с PHPUnit на примере формы?

Question

[Brucey]

Доброго дня.

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

Вот возьмём простейший пример: имеем форму для комментирования на сайте. Допустим, мы забыли сделать экранирование, и теперь при наличии одинарной кавычки в тексте комментария SQL-запрос ломается и выдаёт ошибку + получаем уязвимость для инъекций.

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

Кажется, я не понимаю саму концепцию. Объясните, пожалуйста.

P.S. И если можно, примерчик из практики.

Answer 1

[Алексей Уколов]

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

Тесты часто пишутся до кода и являются прекрасной возможностью продумать граничные случаи заранее. Когда вы пишете код, вы думаете об "удачной" ветке выполнения - как сделать, чтобы функционал заработал. Когда вы пишете тесты, вы наоборот идёте по "пессимистичной" ветке - что может пойти не так во время выполнения? В первом случае легко что-то забыть, потому что голова уже занята деталями реализации.

Кроме того, если писать сначала тесты, а потом код, будет улучшаться архитектура (в теории, разумеется). Покрывать тестами код с кривой архитектурой очень-очень больно, поэтому из чистой лени вы будете стараться следовать всяким SOLID'ам, KISS'ам, YAGNI и прочим акронимам.

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

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

Comments

[Brucey]

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

[D']

Думаю стоит добавить линк на вики для больше ясности.

[Brucey]

D' Normalization: это я читал, все равно не понял, т.е. понял на каком-то абстрактном уровне, а на практическом - никак, т.к. не понимаю несколько базовых вещей.

[Алексей Уколов]

Никакого "ручного тестирования" не нужно. Если у вас есть маленькие объекты с чётко определёнными обязанностями, вы легко можете в голове продумать все пути исполнения.
Я считаю, что заморачиваться не нужно: покрывайте тестами все кейсы, которые придут в голову, а если что-то забыли - потом добавите.

[Алексей Уколов]

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

[D']

Brucey: суть в том, чтобы писать тесты ДО кода. Сначала тесты, потом для них код который заставит тесты работать.
Тестирование довольно сложная тема, и нормальные примеры (из жизни) найти очень сложно. В основном везде одни калькуляторы.
Нужно просто начать писать тесты ДО кода, и тогда придет просветление и понимание. Сначала будет сложно и непонятно, но со временем втягиваешься.