Как предотвратить разрушение покрытия кода разработчиками бесполезными утверждениями?

Question

Я просматривал код разработчика и нашел несколько примеров написания тестов разработчиками, которые помогают пройти покрытие кода, но не добавляют никакого реального значения, например: -

  @Test
  public void testProcess() {
    createInvestorResponseTransformer.process(exchange);
    Assert.assertNotNull("The exchange object should not be NULL.", exchange);

  }

Неизменно в некотором роде используется assertNotNull,

У нас уже есть обзоры кода, и это не было получено.Что я могу сделать, кроме обучения разработчиков по написанию лучших модульных тестов и их ценности, чтобы улучшить ситуацию?

Всегда будет способ игры / подрыв системы, но могу ли я каким-то образом предотвратить большинство из них с помощью SonarQube?

Answer 1

Полное покрытие кода не всегда приятно.

Протестированный код имеет огромное преимущество по сравнению с ошибками регрессии уже перед первым выпуском.

Однако слишком раннее выполнение покрытия кода замедляет развитие и означает переписывание тестов по мере того, как код перерабатывается во время разработки.

И тогда достаточно часто тест становится более или менее бессмысленным.

Илиэто сложно, когда код написан без правильных точек перехвата, возможных зацепок. Это, по крайней мере, должно потребовать рефакторинга.

Так что достаточно соблазна и самооправдания, чтобы снять с охраны покрытие кода, по крайней мере, «на данный момент».

Перед обвинением: - полное покрытие кода - не идеальное покрытие кода: бессмысленно, слишком дорого как с точки зрения качества поставляемого кода, так и скорости разработки

Решение: - все, что ниже 15% покрытия кода, фактически не должно считаться отрицательным

Для этого решения потребуется новый SonarQube.Или осознайте, что SonarQube несовершенен.

Следует понимать, что SonarQube не всегда лучший судья.

Он предпочтет:

A[] a = list.toArray(new A[list.size()]);

,

A[] a = list.toArray(new A[0]);

Как ни странно, второе решение лучше (быстрее), т. Е. Поскольку список в массив использует другую, более быструю реализацию уровня байтового кода.

---

Конечно однодолжен предотвращать такую ​​подрывную деятельность

• Непрерывный анализ также модульных тестов;что ты сделал.Сделать билеты.Цена, которую нужно заплатить.
• Либо разрешите отремонтировать блок тестового примера, либо добавьте комментарий, чтобы не тестировать эту функцию.
• Вручную снимите пометки с предупреждений sonar-qube при наличии комментария
• Вместо комментария возможно использование @SuppressWarnings;без понятия