Я несколько раз сталкивался с TDD (разработка через тестирование) до того, как подал заявку в Andela, но я никогда не относился к этому достаточно серьезно, чтобы выделить время на изучение того, что это такое и как оно работает. Все, о чем я действительно заботился тогда, это о том, что мой код работает нормально. Я имею в виду, почему кто-то должен беспокоиться о чем-то еще.

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

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

Поэтому я погрузился в Homestudy Анделы и начал читать все статьи, перечисленные в разделе TDD. Через несколько минут я получил ответ на свой первый вопрос, TDD определенно не был приложением, предназначенным для того, чтобы делать за вас всю грязную работу за считанные секунды, вместо этого тесты представляли собой сам код, который писался и запускался вручную. Итак, по сути, мы пишем код, чтобы протестировать какой-то другой код.

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

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

Я был буквально поражен тем, как были реализованы тесты. Используя среды тестирования, такие как Jasmine или Mocha, вы можете написать модульные тесты, которые вызывают функции, предоставляют аргументы, а затем проверяют, действительно ли полученные результаты являются ожидаемыми. Некоторые библиотеки утверждений, такие как Chai, позволяют выполнять HTTP-запросы к конечным точкам. Короче говоря, TDD служит реальным способом измерения эффективности вашего кода.

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

  • Это делает совместную работу намного проще и эффективнее, члены команды могут вносить изменения в базу кода с полной уверенностью, что модульные тесты сообщат им, если вносимые ими изменения негативно повлияют на код.
  • TDD упрощает поддержку и рефакторинг кода. Это обеспечивает ясность во время фактической реализации кода.
  • Это помогает прояснить и изолировать требования конкретной функции, потому что вы должны выяснить конкретно, какие входные данные вы должны ввести в программу и какие результаты ожидать.
  • Это также побуждает разработчиков писать только наименьший / минимальный объем кода, необходимый для прохождения тестов, поэтому это может сделать процесс кодирования более рациональным и объективным.
  • А поскольку вы пишете небольшие тесты за раз, ваш код становится более модульным и абстрактным.

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