Защита кода от самих себя

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

Это приводит нас к еще одному очень знакомому месту в жизни разработчика программного обеспечения: бездне неуверенности в себе, где вы в конечном итоге кричите себе:

'Как это вообще могло быть так сложно ?!'

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

Ты будешь делать это снова

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

Итак, как вы можете защитить свой код от его собственного создателя?

Автоматические тесты!

(я думаю, вы это видели)

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

Рад встрече

Для тех, кто не знаком с этой концепцией, автоматическое тестирование - это практика написания процедур, которые тестируют функции вашего приложения. Эти процедуры обычно основаны на фреймворках и библиотеках утверждений, таких как Mocha и Chai (для nodeJs) или Pytest (для python) среди других.

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

  • Если функция получает файл .csv в качестве входных данных, она должна сгенерировать выходной файл в определенном каталоге с тем же именем и расширением. pdf , а также вернуть статус 200 в запрос.
  • Если функция получает файл в любом формате, кроме .csv, она должна вернуть статус 400 вместе с сообщением об ошибке: «Недопустимый формат файла».

Вот еще один пример того, как выглядит автоматизированный тест, но теперь на nodeJs с использованием mocha и chai в другом сценарии. Вы можете найти полный репозиторий исходного кода здесь.

Это наша реализованная функция:

А это примеры тестов, реализованных с использованием Mocha и Chai:

И, наконец, вот результат успешного выполнения теста:

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

Так почему это важно?

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

Сколько мне нужно тестировать?

Как только вы начнете писать тесты, вы поймете, что существует бесконечное количество сценариев, которые нужно тестировать, и в конечном итоге задаетесь вопросом, достаточно ли вы этого (а может быть, слишком много). Вот для чего нужны инструменты c охвата оды! Покрытие кода - это индикатор, который определяет (в процентах), сколько строк исходного кода выполняется при запуске тестов. Например, Istanbul - это фреймворк NodeJs, который может помочь вам с этой задачей.

Помните, что вы не стремитесь покрыть 100% ваших строк кода, в Интернете много обсуждается о покрытии кода и процентах охвата функциональности, но ни у кого нет волшебного числа, чтобы определить, какой объем вашего кода должен охватывать, это Вам как разработчику решать, насколько критична ваша система и, следовательно, насколько она «пуленепробиваемой».

Импровизировать, приспосабливаться, преодолевать

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

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

GIT: github.com/IagoGodoy/basicNodeJsAutomatedTests

Фреймворки:
- mochajs.org
- chaijs.com
- pytest.org
- istanbul.js.org

Принесите свой план в IBM Garage.

Готовы узнать больше о работе с IBM Garage? Мы здесь, чтобы помочь. Свяжитесь с нами сегодня, чтобы обсудить со специалистом Garage вашу следующую большую идею. Узнайте о нашем методе IBM Garage Method, сообществах дизайнеров, разработчиков и стартапов, в которых мы работаем, а также о наших глубоких знаниях и возможностях.

Запланируйте бесплатное посещение в IBM Garage.