Чи корисно використовувати методи тестування, де єдиною логікою є охоронці?

Скажіть, у мене такий метод:

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 для написання одиничних тестів, чи ви можете витратити частину періоду якості QA. робити одиничні тести або, можливо, просто мати справу з перевіреним кодом без підрозділу. На жаль, графіки, які непорушно змушують вас піти на поступки або працювати на смерть, я, як правило, пропоную перший варіант, оскільки другий призведе до того, що ви не зможете підтримати / правильне підтримання системи на термін її роботи.

Це сказав до вашого загального питання про тестування заяв охоронців; Так! Абсолютно тестові заяви охоронців! Ті , є важливими складовими поведінки цього методу, ви не хотіли б, щоб дізнатися, хто що - то робить незрозумілий баг-фікс і видалити ваші охоронець або зміни &&Ань ||б ви? Експертні тести забезпечать, що: а) ви фактично виправили логіку на ваших гвардіях; б) ніхто не порушує цю логіку пізніше, не отримуючи скарги, коли вони проводять тестові одиниці, говорячи, що це повинно бути саме так.

Наведені вище відмінні відповіді, і їхні пункти дуже важливі. Але одне, що, здається, було пропущено, - це те, що у вас є вичерпний набір одиничних тестів, вони читаються як надзвичайно детальна специфікація коду. Якщо ви пропустите перевірку перевірки лише тому, що код такий простий, важко зрозуміти, як це може піти не так, частина вашої специфікації відсутня. Якби я потрапив до команди, де ці тести були пропущені, я б припустив, що ваша служба не підтверджує свої аргументи.

Код - код. Вам слід спробувати отримати 100% охоплення при тестуванні. Якби це не було важливо, його не було б там.