Это сообщение — выдержка из моей новой рассылки The Pragmatic Dev, посвященной инструментам для разработчиков, советам, хитростям и сопутствующим ресурсам. Пожалуйста, подпишитесь.
Прежде всего, я хочу извиниться перед своими подписчиками за то, что до сих пор не опубликовал выпуск. Я планировал сделать это в начале месяца, но моя жизнь была выведена из равновесия увольнением, и потребовалось некоторое время, чтобы переориентировать свою жизнь в условиях поиска работы. Тем не менее, я намерен публиковать эту рассылку еженедельно, предпочтительно по вторникам. Итак, без лишних слов, давайте перейдем к этому выпуску.
Этот выпуск был вдохновлен ответом на твит, который я опубликовал на этой неделе:
Майна Уайклифф@mwycliffe_devДля вас это Test Driven Development или Test During Development?#100DaysOfCode #webdev #программирование
13:51 PM — 20 Jul 2022
И ответ, который я получил от Доминика Фрея и с которым я полностью согласен, вдохновил меня на этот пост.
Доминик Фрей@dominicfrei@mwycliffe_dev Test Driven всегда, когда это возможно. Каждый раз, когда я этого не делаю, я злюсь на себя, потому что мне нужно больше времени, я пишу худший код и в итоге могу не покрыть тестами все важные функции.13:54 PM — 20 Jul 2022
Итак, почему TDD?
Я обычно думаю, что написание тестов — это то, с чем мы все можем согласиться, что это хорошо, особенно когда вы сочетаете их с автоматизированными проверками. К сожалению, всякий раз, когда я делюсь этими мыслями с разработчиками, я встречаю больше сопротивления, чем обычно ожидаю. Я сталкиваюсь с такими настроениями, как:
- Клиенты платят мне за написание кода, а не тестов.
- У меня нет времени на написание тестов и так далее.
Но это предполагает две вещи: вы и ваш клиент можете позволить себе регрессии в своем проекте. Мы все были там, делали небольшое изменение, и все переставало работать. А во-вторых, у вас будет достаточно времени, чтобы отследить влияние ваших изменений или исправить любые ошибки и регрессии. Мы все слышали мантру «не нажимайте на кнопку в пятницу», поскольку вы можете не понять, что изменение что-то сломало, пока не станет слишком поздно.
Хорошие тесты помогают облегчить некоторые из вышеупомянутых проблем; они могут предотвратить попадание регрессии в продакшн и выведение всего из строя. Они также облегчают рефакторинг кода.
Хорошие тесты должны проверять ожидаемое поведение, а не внутреннюю работу кода, что означает, что вы можете переписать свой код, а тесты все равно пройдут. Это означает, что вы можете вносить изменения в свой код с большей уверенностью.
Еще одним преимуществом тестов является то, что они сами по себе выступают в качестве документации, но при тестировании различных случаев может использоваться определенный фрагмент кода; это может помочь другим людям, которые придут после вас, понять ваш замысел и как использовать его самостоятельно.
Надеюсь, я хорошо обосновал, почему вы всегда должны писать тесты. Следующий вопрос — почему вы должны писать их до, а не после кода. Многие из нас не любят писать тесты, потому что считают их написание рутинной работой; однако если перестроить свой рабочий процесс так, чтобы писать их заранее, они станут важным активом.
Приходилось ли вам когда-нибудь писать тесты для функции, только чтобы понять, что вы не знаете, что тестировать или как тестировать вашу функцию? Вы бросились писать код, что мы все делали, и забыли подумать о контракте для вашего кода, т.е. о ваших входах и выходах. Еще одна вещь, которая часто случается, когда вы бросаетесь писать код, не подумав, заключается в том, что в большинстве случаев вы впоследствии переписываете большую часть кода, чтобы его было легче тестировать.
Когда вы пишете тесты заранее, вы должны ответить на эти вопросы, прежде чем делать что-либо еще. Прежде чем писать тесты, вы должны сначала четко сформулировать контракт вашего кода — поведение кода, входы и выходы. Во-вторых, иметь письменный план намерений кода, который вы собираетесь написать, т.е. что он делает и чего не делает. И, наконец, как он вписывается в контекст всего остального, то есть проекта и другого кода, который его использует.
Понравилась ли вам эта статья? Подпишитесь бесплатно, чтобы получать новые сообщения и поддерживать мою работу.
Итак, подведем итог: написав тесты заранее, вы получаете следующие преимущества:
- Вы быстрее пишете код; вы уже четко сформулировали свое намерение, и теперь дело за реализацией.
- Вы получаете более быстрый цикл обратной связи; имея на руках тесты, вы можете знать, когда ваша функция движется в правильном направлении. Это, безусловно, лучше ручного тестирования. С помощью таких инструментов, как watch mode в jest и других тестовых бегунов на разных языках, вы можете автоматизировать выполнение тестов при изменении, а не запускать их вручную.
- У вас есть тесты — тесты, которые вы написали раньше, никуда не денутся, поэтому вы сможете использовать их в будущем при рефакторинге и внесении изменений, а также для автоматических проверок перед развертыванием в среде CI. Это позволит вам повысить качество кода в целом по сравнению с отсутствием тестов.
- Это не рутина — тесты становятся неотъемлемой частью рабочего процесса разработки, и вместо того, чтобы казаться рутиной, они начинают ощущаться как актив, который делает вас более продуктивным.