Как стать автором
Обновить

Тестирование кода разработчиками — почему этот аспект цикла разработки в плохом состоянии и что с этим делать

Уровень сложностиСредний
Время на прочтение11 мин
Количество просмотров5.5K
Всего голосов 6: ↑5 и ↓1+7
Комментарии7

Комментарии 7

А вы можете рассказать поподробнее о курсе тестирования в магистратуре?)))))

Добрый день!

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

Думаю на фронте ещё может быть проблема в настройке и поддержании юнит тестов. Сами юнит тесты не встроены в язык как нативная вещь.

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

Напишите, если ещё знаете такие фреймворки на фронте, хочется посмотреть как в них устроено тестирование

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

Для нас разработчиков - тесты косвенно (а за частую с точки зрения бизнеса и замедляют проект) влияют на результат нашего труда (готовые фичи).

Т.е. разработка через тестирование по факту превращается в разработку и тележку с тестированием сверху

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

Unit тесты не являются заменой интеграционным тестам, а ведь в интеграционном тестирование и кроется корень проблемы.

По моему опыту чаще всего из-за того что тестовый стенд этого просто не предполагает

Добрый день!

Правильно понимаю, что у вас какой-то хардварный кейс? Не могу прокомментировать, потому что с таким не работал. Но был бы очень рад узнать подробности. ?

Интеграционные тесты - очень растяжимое понятие. Если мы говорим о тестах, которые покрывают всю систему целиком, то они не являются заменой unit тестам, тут я с вами согласен. Посыл был скорее в том, что для вас не всегда может быть доступен или возможен какой-то один тип тестирования. Такое может произойти из-за специфики экосистемы (как ловко было указано выше с JavaScript) или специфики вашей команды. Тогда вы можете воспользоваться чем-то одним из нескольких возможных уровней тестирования. Это лучше, чем ничего.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории