Search
Write a publication
Pull to refresh
7
0
Александр Асмаков @AVAsmakov

User

Send message

Спасибо!) Действительно, лучше один раз попробовать и понять, подходит или нет.

Немного не понял вопроса. Имеете в виду, что мы еще используем у себя помимо тестов?

Понял). Я передам пожелания коллегам, спасибо!

Спасибо!)
С момента появления МТ у нас, прошел уже практически год, но я бы не сказал, что мы уже совсем-совсем всё внедрили. Периодически все равно что-то допиливаем.

Команд у нас много и конечно мы имеем какой-то точечный фидбек, но как по мне, он все еще недостаточно полный.
Есть команды, которые еще не используют на полную мутационное тестирование, есть команды, где мутационное тестирование уже внедрено в процессы связанные с качеством, таких кстати большинство. Поэтому мы (наша команда) смотрим на косвенные признаки и понимаем как идут дела:
- Смотрим статистику - MSI у сервисов в основном растет (еще бы, ведь его целенаправленно повышают));
- Количество вопросов и фиче-реквестов в профильных чатиках тоже растет;
- Ну и на продуктовых метриках видим, что участники команд активно пользуются внутренними инструментами, причем с каждым днем все активнее.
Как-то так. То что командам/отдельным людям не нравится, выносится на обсуждение и превращается в таски :).

По сути, MSI 100% означает что 100% логики приложения сдублировано в
тестах и каждая особенность реализации отражена в тестах. И я считаю это
вредным, в плане возрастающей цены поддержки. Далее, это значит что
любой коммит всегда будет менять и саму программу и тесты. Т.е.
программист просто пойдёт и напишет точно эту же логику ещё раз в
тестах. В принципе извращённым вариантом этого является копипаст функции
в тесты и сверка резлуьтатов копипасты и основного кода на всех путях
исполнения. Я всегда считал полезным тот тест, который условно
"выборочно" проверяет, что-то типа проверки части деталей из партии.

Это достаточно холиварная тема на самом деле.
Да, поддерживать тесты на уровне становится дороже, это правда. То, что изменение логики влечет за собой изменение и тестов, тоже имеет место быть, и кстати как по мне, то это хороший признак, потому что тесты заставляют тебя держать контракт и помогают ориентироваться в изменениях логики, если ты например новый разработчик, или просто давно не контрибьютил в сервис и все позабыл.
Не соглашусь только по поводу того, что в тестах прямо-таки повторяется логика). Мутационное тестирование не заставляет повторять логику в тестах, а в основном подсвечивает не очень качественные проверки и места для рефакторинга. Это прям львиная доля мутантов из отчетов, которые довелось посмотреть. Ну и конечно же к 100% стремиться - это прям идеально, но мы у себя определили планку в 75% MSI именно потому, что часть проверок может не представлять ценности, такое можно либо скипнуть, либо еще что-то. В этом плане есть некая гибкость конечно же.

AT - имеется в виду Acceptance Testing или же Agile Testing?)

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Works in
Date of birth
Registered
Activity

Specialization

Backend Developer
Middle