Средства доступа для модульного тестирования (геттеры и сеттеры)

Если вы делаете TDD, вам также следует написать тест для геттера и сеттера. Не пишите ни одной строки кода без проверки - даже если ваш код очень прост.

Это своего рода религиозная война за использование тандема геттера и сеттера для вашего теста или за изоляцию каждого из них путем доступа к защищенным членам класса с использованием возможностей вашей платформы модульного тестирования. Как тестировщик черного ящика, я предпочитаю привязывать свой код модульного тестирования к общедоступному api, а не привязывать его к конкретным деталям реализации. Я ожидайте перемен. Я хочу призвать разработчиков к рефакторингу существующего кода. И внутренние компоненты класса не должны влиять на "внешний код" (в данном случае модульные тесты). Я не хочу прерывать модульные тесты при изменении внутренних компонентов, я хочу, чтобы они прерывались при изменении общедоступного api или при изменении поведения. Хорошо, хорошо, в случае неудачного модульного теста не указывайте на единственный источник проблемы. Мне действительно нужно заглянуть в геттер И сеттер, чтобы выяснить, что вызвало проблему. Большую часть времени ваш добытчик очень просто (менее 5 строк кода: например, возврат и необязательная проверка на нуль с исключением). Так что проверка этого в первую очередь не имеет большого значения и не отнимает много времени. И проверка счастливого пути сеттера в большинстве случаев лишь немного сложнее (даже если у вас есть некоторые проверки).

Попробуйте изолировать свои тестовые случаи - напишите тест для SUT (тестируемого субъекта ), который проверяет его правильность без использования других методов (кроме моего примера выше). Чем больше вы изолируете чем больше тест, тем больше ваши тесты выявляют проблему.

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

Для тестировщиков черного ящика рекомендуется использовать phpunit в строгом режим и использовать @обложки, чтобы скрыть сопутствующее покрытие.

Когда вы пишете модульный тест, ваш тест для класса A должен выполняться независимо от класса B. Поэтому ваши модульные тесты для класса A не должны вызывать /покрывать метод класса B.

Если вы хотите идентифицировать устаревший геттер/сеттер и другие "мертвые" методы (которые не используются в производственном коде), используйте для этого статический анализ кода. Интересующий вас показатель называется "Афферентная связь на уровне метода (methodca)". К сожалению, это метрика (ca) недоступна на уровне метода в PHP Depend (см.: http://pdepend.org/documentation/software-metrics/index.html и http://pdepend.org/documentation/software-metrics/afferent-coupling.html ). Если вам это действительно нужно, не стесняйтесь вносить свой вклад в PHP Depend. Опция исключения вызовов из одного и того же класса была бы полезна для получения результата без "сопутствующих" вызовов. Если вы определяете "мертвый метод", попробуйте выяснить, предназначен ли он для использования в ближайшем будущем ( аналог для другого метода с аннотацией @depricated), в противном случае удалите его. В случае, если он используется только в том же классе, сделайте его приватным/защищенным. Не применяйте это правило к библиотечному коду.

План Б: Если у вас есть приемочные тесты (интеграционный тест, регрессионный тест и т.д.), вы можете запустить этот тест без одновременного запуска модульных тестов и без строгого режима phpunits. Это может привести к очень похожему результату покрытия кода, как если бы вы проанализировали свой производственный код. Но в большинстве случаи, когда ваши неблочные тесты не так сильны, как ваш производственный код. Это зависит от вашей дисциплины, является ли этот план Б "достаточно равным" производственному коду, чтобы получить значимый результат.

Дальнейшее чтение: - Книга: Прагматичный программист - Книга: Чистый код

Это распространенный вопрос, но, как ни странно, я не могу найти обманщика на SO.

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

Это также означает, что покрытие кода не должно быть проблемой. Если вы обнаружите средства доступа, которые не охвачены после запуска всех наборов тестов, возможно, они являются избыточными/неиспользуемыми. Удалите их.

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

[Test]
public void UpdatesTogglePauseTooltipBasedOnState()
{
    Assert.That(_mainViewModel.TogglePauseTooltip, Is.EqualTo(Strings.Main_PauseAllBeacons));

    _mainViewModel.TogglePauseCommand.Execute(null);
    Assert.That(_mainViewModel.TogglePauseTooltip, Is.EqualTo(Strings.Main_ResumeAllBeacons));

    _mainViewModel.TogglePauseCommand.Execute(null);
    Assert.That(_mainViewModel.TogglePauseTooltip, Is.EqualTo(Strings.Main_PauseAllBeacons));
}