Цикломатическая сложность справедливо снижается с помощью частных методов?

Question

Использование частных методов для уменьшения CC путем рефакторинга некоторых точек принятия решения в отдельные методы уменьшает CC фактического метода и облегчает чтение, но не уменьшает усилия, чтобы получить полное покрытие ветви в тестировании.

Является ли этоjustifyable?Каков ваш полевой опыт?

Answer 1

Ну, если вам все еще интересно, есть статья, которую я написал на Cyclomatic Complexity

Разрезание вашего кода разными методами не уменьшит сложность, а только поможет улучшить организацию на местном уровне. Единственный реальный способ уменьшить CC - это действительно провести рефакторинг!

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

Answer 2

По моему опыту, это очень распространенная ситуация - когда вы заставляете рабочий код делать все правильно, это усложняет тестирование
Другие примеры включают в себя сокрытие деталей реализации за интерфейсами, отсутствие доступа к объектам ORM для внешних абонентов, предоставление определенной функциональности только через вызовы веб-служб ... и, как правило, наличие API, который, как вы ожидаете, в производственном процессе, ограничивает тестирование довольно часто.

И да, возвращение вашего покрытия после существенного рефакторинга - это боль. Иногда это приводит к обращению вспять общего прогресса, когда функции, которые так сложно протестировать, не тестируются должным образом. Так что я в целом согласен с Фортегой, кроме самого последнего предложения. Не позволяйте вашим тестам гнить. Они вернутся, когда ты этого меньше всего захочешь.

Answer 3

Я не очень понимаю вашу проблему.Очевидно, что рефакторинг логики и точек принятия решения из большого метода в частные методы уменьшит цикломатическую сложность больших методов.Это своего рода точка извлечения методов - она ​​делает большой метод короче и проще, а значит, мы надеемся, что его легче понять и изменить.

Это не обман, это просто делает структуру вашей программы явной.*

, но не уменьшает усилий, чтобы получить полный охват веток в тестировании.

Мне кажется, что это не является следствием.Почему использование частных методов должно облегчать тестирование покрытия?Я никогда не видел, чтобы кто-нибудь утверждал это.Возможно, вы что-то неправильно поняли?

Answer 4

Иногда, делая ваш код приложения менее сложным и более читабельным, вы можете сделать свой тестовый код более сложным и менее читаемым.Однако это не причина не проводить рефакторинг.Читаемость рабочего кода важнее, чем ваши тесты.

Если вы сделаете некоторые методы закрытыми для уменьшения CC и улучшения читабельности, вы можете использовать такую ​​среду, как Mockito, чтобы по-прежнему иметь возможность самостоятельно тестировать частные методы.

Answer 5

Вы никогда не должны реорганизовывать свой код из-за ощущения, что улучшение чисел, выбрасываемых метрикой, хорошо для вашего кода.Вместо того, чтобы идти на цифры и навороченные отчеты (я видел, что это сделано к сожалению), вы должны стремиться понять метрику и то, почему она используется в первую очередь.

Цикломатическая сложность - простая математическая мера, которая только устанавливаетмного разных путей, по которым ваш код может выполнить, если все его ветви перемещены.Так что да, высокая цикломатическая сложность действительно указывает на то, что ваши тесты могут стать более сложными.Но иногда просто не существует более простого способа написания кода с высоким уровнем CC и огромными тестами.Вам просто нужно знать, когда это справедливая практика и когда что-то не так с вашим дизайном.С другой стороны, уменьшение CC путем разбиения кода на методы вовсе не облегчает задачу тестирования, поскольку код должен рассматриваться в любом случае.Это просто число, которое будет выглядеть «красивее».

Примите во внимание следующее: вам поручено разработать код, который реагирует на нажатия клавиш и выполняет некоторую задачу в зависимости от того, какая клавиша нажата.Устройство имеет только фиксированное количество кнопок, что означает, что программное обеспечение должно быть исчерпывающим и не должно быть расширяемым (возьмите этот шаблон команд).

Вы можете написать простое утверждение switch, котороебудет легко читать, вызывая один метод на нажатие кнопки.Это был бы хороший способ быстро и эффективно решить эту задачу.Но контроль над способом получения нажатия клавиш был бы ужасен.Вы должны разделить код?Зачем?Я имею в виду, что он читабелен, отлично справляется со своей задачей, и независимо от того, что вы делаете, ваши тесты все равно должны учитывать каждое нажатие кнопки.Так что рефакторинг не принесет никакой пользы, кроме уменьшения этого числа.

Мой совет - узнать, когда цикломатическая сложность является значимым показателем, а когда нет.Кроме того, попробуйте некоторые советы по реорганизации Micheal из его сообщения в блоге .У него есть твердый совет.