Comments 12
Меня всегда смущали QA, которые лезут в линтеры и юнит-тесты. При том, что хорошие практики внутри репозитория весьма полезны команде, граница между программистами и QA проходит по сайд-эффектам. Юниты - программиские, дальше уже QA.
Это статья об качестве продукта, и то что над качеством должна работать вся команда
Линтеры обеспечивают качество продукции не в большем объёме, чем хороший кофе в офисе, например. Меньше люди раздражаются.
Жесткие правила линтера иногда защищают от дефектов
например жесткая проверка типов в ts (убрать всякие any)
Тогда это уже не линтер. Есть масса анализаторов кода, но называть их "линтеры", это всё равно, что называть компьютер под столом "процессором".
Изначальная задача линтеров - приведение кода к единому внешнему виду без изменения семантики. Правильные кавычки, правильные скобки, правильные отступы.
Статический анализ кода включает lint-еры
а форматировать код в единый стиль - это инструмент prettier
Я думаю, что тесты, реализованные в рамках покрытия кода, являются продуктом, созданным разработчиками для QA. Уровень интеграции различается для отдельного разработчика и тестировщика. Поэтому, я бы сказал, что на совести программиста должны быть и функциональные, и интеграционные тесты. Не будем забывать, что цель разработчика - передать тестировщикам код без багов. Зачастую, QA занимаются тем, что проверяют результат, используя различные стратегии пользования. Эти стратегии могут быть выведены из C-требований, либо, путём пользовательского тестирования интерфейса. Эти стратегии значительно расширяют условия, прописанные в тестах программиста, и если программист будет заниматься таким тестированием, то у него не будет времени наинаписание нового кода. Однако, когда QA находит ошибку, программист обязан закрепить её условия в тестах, независимо от уровня тестирования. Это позволит избежать регресса в будущем. Однако, эта обязанность говорит о том, что тесты, написанные разработчиком, являются частью продукта, создаваемой для QA. Эта часть продукта снижает риск регресса, а также, позволяет новым сотрудникам тестирования получить информацию о существующих проблемах логики. Это хорошо, когда QA читают тесты.
Юнит-тесты пишутся программистами. Для программистов. Даже если QA репортит "клиент теряет 100500 денег из-за того, что вы неправильно умножаете", то:
нужен тест, который проверит, что клиент не теряет 100500 денег в специфичных условиях. Это задача QA.
программист ищет из-за чего там не туда поделилось, и если это не баг в реализации требований, а баг в самом коде (например, ошибочная конвертация float->int перед умножением), то он пишет тест. Этот тест проверяет найденную ошибку, и его задача, как и задача любого хорошего теста - проверять сохраение инварианта. Этот тест не решает бизнес-задачу, он нужен для программистов, чтобы сохранить инвариант.
Попытка всё в компании поставить на колени во имя продукта - это избыточное эго sales-отдела. Нет, программиста в момент исправления не волнует ни клиент, ни sales-директор, ни даже QA, его волнует, что у него инвариант для, казалось бы, частично-рекурсивной функции нарушен.
Линтеры и юнит-тесты - для программистов в первую очередь. Часть юнит-тестов может проверять бизнес-логику (когда она, по чистой случайности, может быть выражена как чистая функция), но считать их вотчиной QA будет большой ошибкой.
Как забавно, что "эксперты", не знакомые с моими клиентами, начинают считать в сети финансовые потери моих клиентов. А сколько денег теряет каждый клиент, содержащий большой штат QA из-за постоянных проблем CI, вызванных нежеланием разработчика проверять свой продукт перед выдачей кода, вы не считали?
Не считали, так я помогу: если есть QA специалист (хотя бы, один) в команде, значит, заказчик уже тратит деньги на интеграционные тесты. Просто, когда программист один, без QA, потери от регресса превышают затраты на отдельного тестировщика. Собственно, парам-пам-пам, для этого и нанимают QA. А число QA разработчиков в штате обратно пропорционально test coverage. То, что вы не умеете быстро писать тесты, или сразу выдавать легко тестируемый код, это только ваша проблема. При нормальном TDD никаких 100500 часов потерь на тесты нет, и быть не может. Уровень интеграционных тестов в разработке и QA - разный. А специалисты, орущие про потери заказчика при написании тестов, это, как-правило, люди, готовые потратить день на написание кнопки, длительное тестирование её функционала на продакшене, а потом - неделю на её переписывание из-за отказа QA принимать работу.
Поэтому, всё же, тесты разработчика - это артефакты для QA. Чем больше покрытие тестами на этапе разработки, тем меньше расход компании на QA. Плюс, это упрощает поиск проблем, когда QA находит баг.
Грань между integration и e2e вполне можно размыть, особенно в маленьких командах QA.Так, как вы написали если от юнит тестов к интеграционным тестам мы переходим. То к e2e мы вынужденно перетикаем.
Почему «осмысленное тестирование» – это важно?