Всю свою программистскую жизнь я не понимал, для чего мне нужно писать тесты. Делал это потому что “надо”.
С точки зрения начальства понятно. Как минимум им “надо”, чтобы мой код работал без ошибок. Но как это поможет моей работе?
«Я все проверил руками, кейсы протестировал. Зачем я тут с постманом сидел, мучался, чтобы потом еще тесты пилить? Ну и запилю я тесты, все ведь итак работает»
Думаю, многих начинающих программистов (и не только) одолевают такие же сомнения. Я с такими мыслями жил, пока работал в найме.
Когда я стал работать на себя, я очень часто стал задумываться о том, как оптимизировать свою работу. То есть как делать больше и лучше в меньшие сроки.
В поисках ответа я перечитал много книг. Одной из них оказалась “Экстремальное программирование: разработка через тестирование”. На самом деле я на нее наткнулся не специально, а просто лежала в отложенных.
Сразу скажу: первая часть книги про Java и все примеры на нем, а вторая часть на Python. Однако мне так хотелось покодить, что я всю первую часть повторил на питоне
В процессе чтения книги и перевода примеров на удобный для меня язык я осознал следующие вещи:
⁃ Тесты нужны самому разработчику, чтобы понять, что он делает все верно.
⁃ Тесты могут выступать для разработчика удобно оформленными ТЗ.
⁃ Они помогают не сломать уже написанный код.
⁃ Элементарные тесты помогут экономить время на проверку кода.
Сами по себе эти пункты кажутся невероятно очевидными, но для меня тогда они стали просветлением. Давно заученные правила раскрылись для меня по-новому. Я наконец-то увидел пользу в этих действиях.
Ведь напиши я сразу тесты по заданию, которое у меня есть, я изначально обеспечиваю себе четкие границы задачи. Позже мне не нужно сидеть над кодом и думать, что я здесь не учел. Тесты сами по себе мне все показывают. Они помогают освободиться оперативную память моего мозга для того, чтобы пилить код, думать над оптимальностью решения, а не над тем, что я тут еще не учел из задания.
Что касается поддержки работоспособности проекта, то тесты очень выручают. Особенно когда речь идет о большом проекте, в котором уже не помнишь всех нюансов, а надо изменить чуть-чуть. Вот это «чуть-чуть» и приводит, как правило, к падению всего проекта. Новая связь или переименование поля — весь проект лежит, потому что это было ключевое поле в других моделях.
Что касается времени: может казаться, что я без проблем исправлю ошибку, если она вообще вылезет. Я, как человек, который любит все анализировать, сопоставил время на реализацию проектов до и после. Получилось, что на процесс от постановки до принятия задачи у меня стало уходить в 1,5-2 раза меньше времени после того, как я начал писать тесты.
Поначалу это было нудно и не интересно. Но потом я втянулся и стало нереально круто! Теперь получаю кайф от процента покрытия (но, главное сильно не увлекаться) и от того, что все 1000+ тестов в проекте проходят и не падают.
Пишите тесты, экономьте свое время! А чтобы проникнуться идеей, почитайте книгу Кента Бека. Мне она помогла переосмыслить всю разработку.
