Комментарии 5
что-то делали для анализа покрытия кода тестами?
анализ показывает отсутствие тестов, хотя они в проекте присутствуют.
сам нашел ответ:
dotnet tool install --global dotnet-coveragedotnet sonarscanner begin ... /d:sonar.cs.vscoveragexml.reportsPaths=coverage.xml
dotnet build --no-incremental
dotnet-coverage collect -f xml -o coverage.xml dotnet test
dotnet sonarscanner end ...
ИМХО подход наивный. У меня проект перед глазами проект на 6кк строк кода.
Большинство старых ошибок не стреляют. Брать их во внимание при планировании следующего спринта — прекратить разработку. Сонар раскрывается при регулярном анализе. Вот ошибка в новом коде — это потенциальная беда, так как у пользователей еще не было шансов сообщить, что она приводит к проблеме.
К счастью, окошко/фильтр "новый код" в сонаре есть. Хотя просмотреть отдельные совсем жесткие правила в которых почти не бывает ФП и они череваты серьезными травмами (типа итератор не используется в цикле, или какая еще жесть бывает в языке, на котором написан проект) при начале работы на новом проекте стоит.
Спасибо, действительно, мысль очень правильная — в приоритете править новые ошибки; ведь те, что посажены давно, возможно, уже даже в глазах пользователей нашли привыкание (разумеется, это — грустно). Но, как Вы правильно заметили, на это в SonarQube есть инкрементальный отчёт.
Мне же было полезно пробежать "глазами" весь репозиторий на предмет поиска критических с точки зрения безопасности замечаний, понять актуальное состояние и пофиксить особенно пугающие проблемы перед тем, как пытаться проходить внешние тесты на безопасность (и получать соответствующие лицензии).
Подсвечиваем проблемные зоны на коленке с SonarQube и Docker Desktop