Unit тесты

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

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

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

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

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

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

Что трестировать? Желательно трестировать все. Конечно, с помощью тестов можно трестировать только backend, интерфейсы тут протестировать проблематично, поэтому никогда, нет, я бы даже сказал НИКОГДА, код логики не должен быть смешан с представлением. Это проблема большинства дельфистов и драгенддроперов, которые создают обработчик события, и тут же пишут тупо код. Если вы это делаете, избавляйтесь от этой привычки.

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

У меня в команде можно написать любую фигню, но нельзя смешивать код и желательно не делать ошибок безопасности. За этими двумя вещами я стараюсь следить и именно за этим я делаю code review всего, что летит в git.

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

Да, я пишу юнит тесты для себя не для того, чтобы они завершились успешно, а для того, чтобы протестировать свой код. Я вообще очень рассеянный, постоянно делаю мелкие ошибки типа лишнего нолика поставлю (100 вместо 10) или могу поставить 1 вместо 0, потому что пишу код достаточно быстро и меня постоянно дергают менеджеры проекта, а когда тебя отвлекают, писать нормально не получается, просто не могу быть сосредоточенным. Поэтому я отношусь к тестированию серьезно. Ведь чем лучше я смогу проверить свой код с помощью тестов, то более качественный продукт я смогу предоставить клиенту.

Была бы моя воля, я бы держал в команде отдельного человека, который бы писал тесты для других программистов. Но моя воля далеко не всегда то же самое, что принято в компании. Я понимаю, что у нас новой разработки не так уж и много, чтобы держать круглый год отдельного человека, а держать одного человека на два проекта не получится. Просто этот человек должен знать всю систему досконально, чтобы писать эффективные тесты. А знать сразу несколько проектов досконально – проблематично. Поэтому приходится писать самим себе. Но это нормально, если относится к этому серьезно.

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

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

---

Внимание!!! Если ты копируешь эту статью себе на сайт, то оставляй ссылку непосредственно на эту страницу. Спасибо за понимание