show

40

Обзор книги про TDD

Всю свою программистскую жизнь я не понимал, для чего мне нужно писать тесты. Делал это потому что “надо”.
С точки зрения начальства понятно. Как минимум им “надо”, чтобы мой код работал без ошибок. Но как это поможет моей работе?

«Я все проверил руками, кейсы протестировал. Зачем я тут с постманом сидел, мучался, чтобы потом еще тесты пилить? Ну и запилю я тесты, все ведь итак работает»
Думаю, многих начинающих программистов (и не только) одолевают такие же сомнения. Я с такими мыслями жил, пока работал в найме.

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

В поисках ответа я перечитал много книг. Одной из них оказалась “Экстремальное программирование: разработка через тестирование”. На самом деле я на нее наткнулся не специально, а просто лежала в отложенных.

Сразу скажу: первая часть книги про Java и все примеры на нем, а вторая часть на Python. Однако мне так хотелось покодить, что я всю первую часть повторил на питоне

В процессе чтения книги и перевода примеров на удобный для меня язык я осознал следующие вещи:
 ⁃ Тесты нужны самому разработчику, чтобы понять, что он делает все верно.
 ⁃ Тесты могут выступать для разработчика удобно оформленными ТЗ.
 ⁃ Они помогают не сломать уже написанный код.
 ⁃ Элементарные тесты помогут экономить время на проверку кода.

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

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

Что касается поддержки работоспособности проекта, то тесты очень выручают. Особенно когда речь идет о большом проекте, в котором уже не помнишь всех нюансов, а надо изменить чуть-чуть. Вот это «чуть-чуть» и приводит, как правило, к падению всего проекта. Новая связь или переименование поля — весь проект лежит, потому что это было ключевое поле в других моделях.

Что касается времени: может казаться, что я без проблем исправлю ошибку, если она вообще вылезет. Я, как человек, который любит все анализировать, сопоставил время на реализацию проектов до и после. Получилось, что на процесс от постановки до принятия задачи у меня стало уходить в 1,5-2 раза меньше времени после того, как я начал писать тесты.

Поначалу это было нудно и не интересно. Но потом я втянулся и стало нереально круто! Теперь получаю кайф от процента покрытия (но, главное сильно не увлекаться) и от того, что все 1000+ тестов в проекте проходят и не падают.

Пишите тесты, экономьте свое время! А чтобы проникнуться идеей, почитайте книгу Кента Бека. Мне она помогла переосмыслить всю разработку.

Есть вопросы?

Хотите обсудить проект?

Напишите нам!