Полезно ли использовать методы юнит-тестирования, где единственная логика - это охрана

Скажем, у меня есть такой метод:

public void OrderNewWidget(Widget widget)
{
   if ((widget.PartNumber > 0) && (widget.PartAvailable))
   {
        WigdetOrderingService.OrderNewWidgetAsync(widget.PartNumber);
   }
}

У меня есть несколько таких методов в моем коде (передняя часть асинхронного вызова веб-службы).

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

Часть меня говорит: «Конечно, вы можете тестировать их, но это не стоит времени» (я работаю над проектом, который уже отстает от графика).

Но другая сторона меня говорит, что если вы не тестируете их модулем, а кто-то меняет Страж, тогда могут быть проблемы.

Но первая часть меня говорит обратно: если кто-то меняет охрану, то вы просто делаете для них больше работы (потому что теперь им нужно сменить охранников и юнит-тесты для охранников).

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

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

Часть меня говорит: «Конечно, вы можете тестировать их, но это не стоит времени» (я работаю над проектом, который уже отстает от графика).

Это три очень коротких теста. Вы потратили столько времени, чтобы задать себе вопрос.

Но другая сторона меня говорит, что если вы не тестируете их модулем, а кто-то меняет Страж, тогда могут быть проблемы.

Послушай эту сторону.

Но первая часть меня говорит обратно: если кто-то меняет охрану, то вы просто делаете для них больше работы (потому что теперь им нужно сменить охранников и юнит-тесты для охранников).

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

Первая часть вас просто неправильно. Дайте второй части похлопать по спине и перестаньте думать об этом.

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

В Widgetклассе

public bool IsReadyForOrdering { get { return PartNumber > 0 && PartAvailable; } }

или эквивалентный метод где-то еще

public bool IsWidgetReadyForOrdering(Widget widget)
{
    return widget.PartNumber > 0 && widget.PartAvailable;
}

Метод заказа

public void OrderNewWidget(Widget widget)
{
   if (IsWidgetReadyForOrdering(widget)) {
        WigdetOrderingService.OrderNewWidgetAsync(widget.PartNumber);
   }
}

Теперь тестирование IsWidgetReadyForOrderingстало легким. Не думай больше об этом. Проверь это!

Если у вас нет времени в вашем расписании для модульного тестирования, но у вас есть время отложить на твердое использование QA, спросите, можете ли вы украсть часть этого времени для написания модульных тестов или можете потратить часть периода QA проводить модульные тесты, или, возможно, просто иметь дело с не тестируемым модулем кодом. К сожалению, графики, которые являются неподвижными, вынуждают вас идти на уступки или работать самостоятельно до смерти, я обычно предлагаю первый вариант, потому что второй приведет к тому, что вы не сможете поддерживать / поддержание системы в течение срока ее действия.

Тем не менее, на ваш общий вопрос о проверке охранных заявлений; Да! Абсолютно проверить охранные высказывания! Это важные части поведения этого метода, вы бы не хотели, чтобы кто-то неправильно понял, что-то делает исправление ошибки, снял вашу охрану или поменял ее &&на другую, ||не так ли? Модульные тесты гарантируют, что: а) вы действительно правильно поняли логику своих охранников и б) никто не нарушит эту логику позже, не получив жалоб, когда они запустят юнит-тесты, говорящие им, что так должно быть по какой-то причине.

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

Код есть код. Вы должны попытаться получить 100% покрытие при тестировании. Если бы это не было важно, его бы там не было.