Одиничне тестування декількох умов в операторі IF

У мене шматок коду, який виглядає приблизно так:

function bool PassesBusinessRules()
{
    bool meetsBusinessRules = false;

    if (PassesBusinessRule1 
         && PassesBusinessRule2
         && PassesBusinessRule3)
    {
         meetsBusinessRules= true;
    }

    return meetsBusinessRules;
}

Я вважаю, що для цієї конкретної функції повинно бути чотири одиничні тести. Три, щоб перевірити кожне з умов у операторі if і переконатися, що воно повертає помилкове. І ще один тест, який гарантує, що функція повертає істину.

Питання: Чи насправді замість цього має бути десять одиничних тестів? Дев'ять, що перевіряє кожен із можливих шляхів відмови. IE:

• Неправдивий хибний хибний
• Неправдива помилкова правда
• Неправдива правда

І так далі для кожної можливої ​​комбінації.

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

Формально ці типи покриття мають назви.

По-перше, є покриття предикатами : ви хочете мати тестовий випадок, який робить оператор if справжнім, і той, який робить його помилковим. Дотримання цього покриття, ймовірно, є основною вимогою для хорошого набору тестів.

Потім з'являється Покриття стану : Тут ви хочете перевірити, що кожна підзамова в системі if має значення true та false. Це, очевидно, створює більше тестів, але зазвичай виловлює більше помилок, тому часто корисно включити у свій тестовий набір, якщо у вас є час.

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

Це краще, ніж простий присудок або покриття умови? Що стосується покриття, звичайно. Але це не безкоштовно. Це дуже дорога вартість тесту на обслуговування. З цієї причини більшість людей не турбуються повним комбінаторним покриттям. Зазвичай тестування всіх гілок (або всіх умов) буде досить хорошим для лову помилок. Додавання додаткових тестів для комбінаторного тестування зазвичай не може наздогнати більше помилок, але потрібно створити та підтримувати багато зусиль. Зазвичай додаткові зусилля роблять це не вартим дуже маленької окупності, тому я б не рекомендував цього.

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

Зрештою, це залежить від вас (r команда), коду та конкретного середовища проекту. Не існує універсального правила. Ви (команда) повинні написати стільки тестів, скільки вам потрібно, щоб почувати себе комфортно, що код справді правильний . Тож якщо ваших товаришів по команді не переконують 4 тести, можливо, вам потрібно більше.

Час OTOH для написання одиничних тестів зазвичай є дефіцитним ресурсом. Тому прагніть знайти найкращий спосіб провести обмежений час, який у вас є . Наприклад, якщо у вас є інший важливий метод з 0% охопленням, може бути краще написати пару одиничних тестів для покриття цього, а не додавати додаткові тести для цього методу. Звичайно, це також залежить від того, наскільки тендітним є виконання кожного. Планування багатьох змін цього конкретного методу в осяжному майбутньому може виправдати додаткове охоплення тесту. Тож може бути на критичному шляху всередині програми. Це все фактори, які може оцінити лише ви (команда).

Я особисто був би задоволений 4-ма тестами, які ви окреслили, тобто:

• справжнє хибне хибне
• false справжній false
• false false true
• справжній справжній правдивий

плюс, можливо, один:

• справжнє справжнє хибне

переконатися, що єдиний спосіб отримати прибуткову вартість - trueце задоволення всіх трьох правил бізнесу. Зрештою, якщо ваші товариші по команді наполягають на покритті комбінаторних доріжок, можна додати ці додаткові тести, ніж продовжувати аргумент набагато довше :-)

Якщо ви хочете бути в безпеці, вам знадобиться вісім тестових одиниць, використовуючи умови, представлені трьома таблицями змінної істинності ( http://teach.valdosta.edu/plmoch/MATH4161/Spring%202004/and_or_if_files/image006.gif ).

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

Так, має бути повне поєднання в ідеальному світі.

Роблячи тест одиниці, ви дійсно повинні намагатися ігнорувати, як працює метод. Просто введіть 3 входи та переконайтесь, що вихідний результат правильний.

Держава - зло. Наступна функція не потребує одиничного тесту, оскільки вона не має побічних ефектів і добре розуміє, що робить, а що не робить. Навіщо це тестувати? Ви не довіряєте своєму власному мозку ??? Статичні функції чудові!

static function bool Foo(bool a, bool b, bool c)
{
    return a && b && c;
}

Я знаю, що це питання досить старе. Але я хочу дати ще одну точку зору на проблему.

По-перше, ваші одиничні тести повинні мати дві цілі:

1. Створіть документацію для вас та ваших товаришів по команді, щоб через певний проміжок часу ви змогли прочитати одиничний тест і переконатися, що ви розумієте what's the class' intentionтаhow the class is doing its work
2. Під час розробки модульний тест гарантує, що код, який ми записуємо, виконує свою роботу так, як це було призначено нашим розумом.

Отже, рекапітуючи проблему, ми хочемо протестувати a complex if statement, для даного прикладу є 2 ^ 3 можливості, тобто важлива кількість тестів, які ми можемо написати.

• Ви можете адаптуватися до цього факту і записати 8 тестів або скористатися параметризованими тестами
• Ви також можете слідувати за іншими відповідями і пам’ятати, що тести повинні бути чіткими з наміром, таким чином ми не збираємося возитися з занадто великою кількістю деталей, які в найближчому майбутньому можуть ускладнити розуміння what is doing the code

З іншого боку, якщо ви знаєте, що ваші тести ще складніші за впровадження, це тому, що реалізація повинна бути перероблена (більш-менш залежно від випадку), а не сам тест.

Наприклад, для складних, якщо висловлювань, ви можете подумати про схему відповідальності ланцюга , реалізуючи кожен обробник таким чином:

If some simple business rule apply, derive to the next handler

Наскільки просто було б перевірити різні кілька простих правил, а не складне правило?

Сподіваюся, це допоможе,

Це один із тих випадків, коли щось на зразок швидкої перевірки ( http://en.wikipedia.org/wiki/QuickCheck ) стане вашим другом. Замість того, щоб виписувати всі N випадків вручну, комп'ютер змусить генерувати всі (або принаймні велику кількість) можливих тестових випадків і підтвердити, що всі вони приносять чудовий результат.

Ми програмуємо комп’ютери для життя на цьому, чому б не запрограмувати комп'ютер для створення тестових випадків для вас?

Ви можете переробити умови на умови охорони:

if (! PassesBusinessRule1) {
    return false;
}

if (! PassesBusinessRule2) {
    return false;
}

if (! PassesBusinessRule3) {
    return false;
}

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

(Зверніть увагу, що я великий вентилятор "єдиної точки виходу", але я роблю виняток для умов охорони. Але є й інші способи структурувати код, щоб у вас не було окремих повернень.)