Я фанат тестов. Очень люблю, когда основные части моего кода покрыты полностью, от и до. Первая очевидная причина, для чего это нужно: если я закрываю задачу, то должен более-менее точно знать, что действительно ее выполнил. Тесты помогают получить такую уверенность.
Вторая причина: хочется иметь возможность безболезненно вносить изменения и проводить рефакторинг. Наличие тестов позволяет делать это, пусть и с опаской. Если тестов нет, то рефакторинг либо невозможен, либо может стать серьезным испытанием для команды, ведь придется проводить регрессионное тестирование большого количества функционала.
Подход, который я долгое время использовал массово - написание юнит-тестов с использованием Mockito. В заглушки превращается любой сторонний сервис, используемый тестируемым классом. Тесты супер-быстрые, все зеленое, все супер!
Со временем я заметил, что этот подход начал изрядно напрягать. Часто на две строчки кода приходилось писать не менее 10-20 строк теста.
Огромное количество переопределений поведения заглушек. Проверки, что тот или иной метод сторонних сервисов более не вызывался или вызывался не более определенного количества раз. Без преувеличения, огромное количество бойлер-плейт кода в тестах.
Дальше - больше. Множество зеленых галочек, появляющееся на экране при запуске тестов, не могло не радовать. Но вот ты решаешь сделать минимальный рефакторинг, оптимизировать какой-то метод. В этот момент все разваливается на куски. Куча красных тестов! Как, почему? Да просто во внутренней реализации ты перешел на использование другого метода, добавил в метод еще один параметр или что-то подобное. В результате куча тестов перестала работать. И теперь, поменяв одну строчку в процессе рефакторинга, надо поменять еще 30 строк в тестах. В какой-то момент начинаешь ловить себя на мысли - “Ни в коем случае, никаких рефакторингов больше!”
Автор: Парвин Хан (Parveen Khan) Оригинал статьи Перевод: Ольга Алифанова
Что такое bug bash?
Вам когда-нибудь хотелось превратить тестирование в вечеринку? Bug bash как раз позволяет это сделать! Ну, не всё там сводится к веселью и играм: обычно самый крепкий напиток — это чёрный кофе, и вряд ли вам захочется нанимать диджея – но при этом можно неплохо провести время и заодно узнать важные вещи о продукте и качестве.
Bug bash укрепляет сотрудничество, даёт возможность выслушать разные точки зрения и помогает формировать и укреплять культуру качества. Обычно bug bash выглядит примерно так:
Вы приглашаете кросс-функциональную команду: тестировщиков, разработчиков, продакт-оунеров, дизайнеров, стейкхолдеров. Иногда это просто продуктовая команда, а иногда — люди, которые обычно не ходят на ваши встречи – например, юристы или маркетологи. Важно пригласить и тех, кто ещё не пользовался продуктом (или не пробовал новые фичи).
Вы задаёте общие правила тестирования продукта. Как и на обычной вечеринке, хороший хозяин должен обозначить ожидания и рамки.
Веселитесь! Геймифицируйте тестирование (несколько идей ниже).
В течение нескольких часов или даже нескольких сессий по паре часов команда сосредоточенно тестирует продукт, следуя заданным правилам.