Тестирование кода

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

Периодически изучая, я натыкался на два вида тестирования: юнит тестирование и сквозное.

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

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

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

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

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

инструмент мониторинга покрытия кода тестами

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

пример одного интеграционного теста на Angular

Поняв основные принципы, наткнулся на технику TDD, разработка через тестирование, в основе которой короткие циклы разработки:

  • пишется тест, покрывающий желаемое поведение
  • пишется код, который позволит пройти тест
  • под конец проводится рефакторинг нового кода

Изучаю эту технику, надо сделать замеры насколько медленнее будет разработка.