Комментарии 8
Люди ленивые, мозг молодец:) Всё будет делаться по пути наименьшего сопротивления и максимальной выгоды для себя. У Вас получается разработчику лень писать тесты, а qa не лень возвращать задачу и получать негатив в ответ. Странное и не сработает. Шаблон будет скинуться если есть возможность. Ни какая организационная мера не сработает долгосрочно, о ней нужно регулярно напоминать, как-то проверять, мотивировать. Гораздо проще делать технические ограничения, автоматически проверять покрытие кода тестами и запрещать мержить если нужный порог не достигнут.
Альтернатива, которая будет работать, поощрять рублём за качество кода, но это совсем фантастика.
Альтернатива, которая будет работать, поощрять рублём за качество кода, но это совсем фантастика.
кстати, интересно была бы геймификация этого процесса, т.е.
1) иметь автомат по проверке качества (мне например понравился SonarQube - он непохо ставит оценку % покрытия кода тестами)
2) ставить 1 звезду за покрытие 80% , 2 звезды - за 90%, 3 за 95%, 4 за 98% и 5 - за 100%
4) ставить оценку PR тоже в звездах (можно в обе стороны - автор ревьюверу, и ревьювер автору)
5) делать ежемесячный топчик по категориям звезд за предыдущие три месяца (т.е. берется скользящее среднее за 3 месяца), топ10 - топ3 (смотря какой у вас бюджет) "поощрять рублем" ( + "победитель рейтинга" пропускает следующий месяц, чтобы не было серии :) )
6) трекать конфликты (когда кто-то жалуется что ему занижают оценки или что есть "клика накрутчиков")
но т.к. это все сложно для менеджмента, то разумеется фантастика :D
Код можно покрыть бесполезными тестами, достигнуть 100% покрытия и считать себя молодцом, потратив время впустую.
Моя идея была в другом. Разработчику не лень писать тесты, он просто не привык. А тестировщик хочет, чтобы привык. И для этого пытается выключить автопилот разработчика. Тестировщику не лень, потому что он является заказчиком изменений, для него это важно.
Непонятно. Если код проверяет SonarQube или аналог, разработчик становится вредителем и пишет фиктивные тесты, а если qa то начнет писать сам без напоминания и хорошие, даже покрытие проверять не нужно. Логические нестыковки. Думаю, что условный SonarQube проверит код лучше чем среднестатистический qa, да еще и исключен человеческий фактор и экономия рабочего времени. А qa, раз ему не лень, пусть сам пишет тесты :))
что такое бесполезные тесты? мы же не в штуках меряем, а в % покрытия кода.
100% покрыли - значит норм.
не, я понимаю, что в идеале нужно тестировать краевые условия и т.д. , но давайте быть реалистами - не всегда пишут тесты, которые просто проверяют что при вызове функции Ф с нужными параметрами она не вызовет исключение, а не то что какую-то умную логику проверки ...
При том, что такой примитивнейший тест уже хотя бы как-то фиксирует АПИ (а не убрали параметр, добавили параметр, и все тесты зеленые, потому что никто не проверил - в продакшен!)
"Нет привычки писать тесты" - это только вершина айсберга. Реальных причин может быть гораздо больше, и работать с ними надо по-разному. Перечислю наиболее типичные варианты:
У разработчика не срабатывает триггер "пора писать тесты" в тот момент, когда это делать эффективнее всего - в самом начале работы над задачей. Человек может не знать о существовании TDD либо не иметь практического опыта в нём. А когда задача завершена, делать для неё ещё и тесты кажется лишней работой. Привычка лучше всего нарабатывается через целенаправленные тренинги (см. code kata, code retreat).
Разработчик вспоминает про тесты, но понимает, что ему не хватит на них времени. Тесты требуют заметного времени на написание, запуск, отладку и подчистку. При наличии прессинга со стороны менеджмента ("мы должны делать всё быстрее") написание автотестов может являться невыгодной стратегией. Особенно если у разрабов мало опыта в этом деле. Поможет только снятие или ослабление прессинга.
Разработчик вспоминает про тесты и даже пытается писать их, но код написан в стиле, который "сопротивляется" тестированию. Например, бизнес-логика и работа с внешними системами (системное время, многопоточность, БД, сеть, диск и т.п.) сильно перемешаны друг с другом. Или код пронизан взаимосвязями без чёткой структуры. Обычно такой код как раз и бывает в системах, которые писали без автотестов. В итоге, недописанные тесты выбрасываются и не попадают в коммит. Здесь помогает регулярный и целенаправленный рефакторинг, который поможет отделить одни части кода от других. А рефакторинг, в свою очередь, должен опираться на автотесты, которых ещё нет :) Здесь можно раскрутить позитивный цикл изменений, но это не получится сделать быстро.
В конечном итоге, всё сводится к комбинации личного опыта разработчиков и внешних условий (качество кода, наличие инфраструктуры, отношение менеджмента, наличие времени на обучение и эксперименты). Если Вы хотите поменять поведение команды, недостаточно "просто договориться" с ними. Предоставляйте им возможности для того, чтобы выработать новые навыки и закрепить их на практике. Ищите способы сокращать цикл обратной связи при обучении. Пробуйте групповые тренинги. Находите энтузиастов в команде разработки, которые горят этой идеей и готовы тащить остальных за собой собственным примером. Гоните ссаными тряпками идеи по "геймификации" из комментов выше - потому что Вам нужен нормальный рабочий процесс, а не судорожные попытки подстроиться под безжалостные машинометрики.
Мозг на автопилоте и внедрение изменений