Чи допомогли б одиничні тести Citigroup уникнути цієї дорогої помилки?

Я читав про цей сніфу: Програмування помилок коштує Citigroup 7 мільйонів доларів після того, як легальні транзакції помилялися з тестовими даними протягом 15 років .

Коли система була запроваджена в середині 1990-х, програмний код відфільтрував усі транзакції, яким було надано тризначні коди філій від 089 до 100, і використовував ці префікси для тестування.

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

(Я думаю, це ілюструє, що використання неявного показника даних є ... неоптимальним. Набагато краще було б заповнити та використовувати семантично явну Branch.IsLiveвластивість.)

Що осторонь, моя перша реакція була "Одиничні тести допомогли б тут" ... але чи вони?

Нещодавно я прочитав Чому більшість одиниць тестування викликає інтерес, і тому моє запитання: як виглядатимуть одиничні тести, які не змогли б ввести буквено-цифрові кодові гілки?

Ви справді запитуєте, "чи допомогли б тут одиничні тести?", Чи ви запитуєте, "чи могли б тут допомогти будь-які види тестів?".

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

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

Крім того, може бути тест інтеграції процедури, яка генерує звіт SEC. Цей тест гарантує, що кожен реальний ідентифікатор філії повідомляє про свої транзакції (і тому вимагає введення в реальному світі, список усіх ідентифікаторів гілок, які використовуються). Тож це теж не одиничний тест.

Я не бачу жодного визначення або документації щодо залучених інтерфейсів, але можливо, тести одиниць не могли виявити помилку, оскільки пристрій не був несправним . Якщо підрозділу дозволено припускати, що ідентифікатори гілок складаються лише з цифр, і розробники ніколи не приймали рішення, що робити з коду, якщо він цього не зробив, то вони не повиннінаписати тест одиниці, щоб застосувати особливу поведінку у разі нецифрових ідентифікаторів, оскільки тест відкине гіпотетичну дійсну реалізацію блоку, який правильно обробляв буквено-цифрові ідентифікатори гілки, і зазвичай не хочеться писати тестовий пристрій, який запобігає дійсності майбутні реалізації та розширення. Або, можливо, в одному документі, написаному 40 років тому, неявно визначено (через деякий лексикографічний діапазон у сировинному EBCDIC, замість більш прийнятного для людини правила зіставлення), що 10B є тестовим ідентифікатором, оскільки він фактично падає між 089 і 100. Але тоді 15 років тому хтось вирішив використовувати його як справжній ідентифікатор, тому "несправність" не лежить у блоці, який правильно реалізує оригінальне визначення: він лежить у процесі, який не помітив, що 10B визначено як тестовий ідентифікатор, і тому його не слід призначати до гілки. Те ж саме станеться і в ASCII, якби ви визначили 089 - 100 як тестовий діапазон, а потім ввели ідентифікатор 10 $ або 1,0. Так буває, що в EBCDIC цифри надходять після літер.

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

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

Я погоджуюся, звичайно, що якби пристрій не було визначено в першу чергу за допомогою "смішної форми", тестувати нічого не було б. Виразно розділити простір імен може бути важко перевірити належним чином, оскільки складність не полягає у здійсненні вашого смішного визначення, воно полягає у тому, щоб переконатися, що всі розуміють і поважають ваше смішне визначення. Це не локальна властивість одного блоку коду. Крім того, зміна деякого типу даних з "рядка цифр" на "рядок буквено-цифрових" схоже на те, щоб зробити обробку програми на основі ASCII Unicode: це буде не просто, якщо ваш код сильно пов'язаний з початковим визначенням, і коли тип даних є основоположним для того, що робить програма, тоді він часто сильно пов'язаний.

трохи заважає думати, що це значною мірою витрачає сили

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

Одиничні тести могли б зрозуміти, що коди філій 10B та 10C були неправильно класифіковані як "тестуючі гілки", але я вважаю малоймовірним, що тести для цієї класифікації філій були б досить обширними, щоб зрозуміти цю помилку.

З іншого боку, точкові перевірки згенерованих звітів могли виявити, що розгалужені 10B та 10C послідовно відсутні у звітах набагато раніше, ніж за 15 років, коли помилка тепер могла залишатися присутнім.

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

Програмне забезпечення повинно було обробляти певні правила ведення бізнесу. Якби були одиничні тести, одиничні тести перевірили б, чи програмне забезпечення правильно обробляло бізнес-правила.

Правила бізнесу змінилися.

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

Тож ні, одиничні тести цього б не впіймали.

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

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

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

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

Ні, не обов’язково.

Початкова вимога полягала у використанні числових кодів гілок, тому для компонента, який приймав різні коди та відхиляв будь-які подібні 10B, було б виготовлено одиничне тестування. Система була б передана як робоча (якою вона була).

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

Тепер ми припускаємо, що люди, що керують системою, знали б, що це так, і змінили б тестовий пристрій для обробки нових кодів ... але якби вони знали, що відбувається, вони також знали б змінити код, який обробляє ці коди все одно .. і вони цього не робили. Тест одиниці, який спочатку відкинув код 10B, із задоволенням сказав би "все добре", коли ви запустите, якби ви не знали оновити цей тест.

Тестування приладів добре для оригінальної розробки, але не для тестування системи, особливо не через 15 років після того, як вимоги давно забуті.

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

Тестування типів (процес тестування інваріантів з використанням випадково згенерованих дійсних даних, як на прикладі тестової бібліотеки Haskell QuickCheck та різних портів / альтернатив, натхненних нею іншими мовами) цілком може наздогнати цю проблему, одиничне тестування майже напевно не зробило б .

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

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

Звичайно, QuickCheck був вперше розроблений у 1999 році, тому вже було пізно, щоб зайнятися цим питанням.

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

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

Виявити цю проблему можна лише за допомогою:

• Інтеграційні тести - але вам доведеться спеціально додавати нові формати коду для подачі через декілька одиниць у системі (тобто вони показуватимуть вам проблему лише у тому випадку, якщо в оригінальні тести були включені чинні гілки)
• Кінцеве тестування - бізнес повинен запустити тест "в кінці", який включає старі та нові формати кодових галузей

Не вистачає достатнього кінцевого тестування викликає занепокоєння. Ви не можете розраховувати на тестування одиниць як ТІЛЬКИ або ОСНОВНИЙ тест для системних змін. Схоже, що потрібно лише комусь запустити звіт про нещодавно підтримувані формати філійного коду.

Твердження, вбудоване в час виконання, могло б допомогти; наприклад:

1. Створіть функцію на кшталт bool isTestOnly(string branchCode) { ... }
2. За допомогою цієї функції можна визначити, які звіти відфільтрувати
3. Повторно використовуйте цю функцію в твердженні, в коді створення гілки, щоб перевірити або стверджувати, що гілка не (не може бути) створена за допомогою цього типу коду філії‼
4. Увімкніть це твердження в режимі реального часу (а не "оптимізовано, за винятком версії коду для розробника", призначеної лише для налагодження)‼

Дивитися також:

• Окремі версії "налагодження" та "випуск"? (тобто увімкніть твердження під час виконання)
• Чи слід перевірити внутрішню реалізацію чи лише перевірити поведінку населення? (тобто, можливо, системні тести корисніші, забезпечують краще покриття, ніж одиничні тести)

Витяг з цього - на Fail Fast .

У нас немає коду, а також не маємо багато прикладів префіксів, які є або не є тестовими префіксами гілок відповідно до коду. Все, що ми маємо, це:

• 089 - 100 => тестова галузь
• 10В, 10С => тестова гілка
• <088 => імовірно реальні гілки
• > 100 => імовірно реальні гілки

Те, що код дозволяє числа та рядки, більш ніж трохи дивне. Звичайно, 10B та 10C можна вважати шістнадцятковими числами, але якщо всі префікси трактуються як шістнадцяткові числа, 10B та 10C потрапляють поза тестовим діапазоном і вважатимуться справжніми гілками.

Це, ймовірно, означає, що префікс зберігається як рядок, але в деяких випадках трактується як число. Ось найпростіший код, який я можу придумати, що повторює цю поведінку (використовуючи C # для ілюстративних цілей):

bool IsTest(string strPrefix) {
    int iPrefix;
    if(int.TryParse(strPrefix, out iPrefix))
        return iPrefix >= 89 && iPrefix <= 100;
    return true; //here is the problem
}

Англійською мовою, якщо рядок є числом і становить від 89 до 100, це тест. Якщо це не число, це тест. Інакше це не тест.

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

assert.isFalse(IsTest("088"))
assert.isTrue(IsTest("089"))
assert.isTrue(IsTest("095"))
assert.isTrue(IsTest("100"))
assert.isFalse(IsTest("101"))
assert.isTrue(IsTest("10B")) // <--- business rule change

Тест одиниці показує, що "10B" слід розглядати як тестову гілку. Користувач @ gnasher729 вище говорить, що правила бізнесу змінилися, і ось що показує останнє твердження вище. У якийсь момент це ствердження повинно було перейти на isFalse, але цього не сталося. Тестові одиниці запускаються під час розробки та часу нарощування, але потім у будь-який момент.

Що тут урок? Коду потрібен певний спосіб сигналізувати, що він отримав несподіваний вхід. Ось альтернативний спосіб написання цього коду, який підкреслює, що він очікує, що префікс буде числом:

// Alternative A
bool TryGetIsTest(string strPrefix, out bool isTest) {
    int iPrefix;
    if(int.TryParse(strPrefix, out iPrefix)) {
        isTest = iPrefix >= 89 && iPrefix <= 100;
        return true;
    }
    isTest = true; //this is just some value that won't be read
    return false;
}

Для тих, хто не знає C #, значення, що повертається, вказує, чи міг код проаналізувати префікс із заданого рядка. Якщо значення повернення є істинним, викликовий код може використовувати змінну isTest out, щоб перевірити, чи є префікс гілки тестовим префіксом. Якщо значення повернення помилкове, викликовий код повинен повідомити, що даний префікс не очікується, а змінна isTest out є безглуздою і її слід ігнорувати.

Якщо ви все з винятками, можете зробити це замість цього:

// Alternative B
bool IsTest(string strPrefix) {
    int iPrefix = int.Parse(strPrefix);
    return iPrefix >= 89 && iPrefix <= 100;
}

Ця альтернатива є більш простою. У цьому випадку викликовий код повинен виловлювати виняток. У будь-якому випадку код повинен мати певний спосіб повідомляти абоненту, що він не очікував strPrefix, який не вдалося перетворити на ціле число. Таким чином код швидко виходить з ладу, і банк може швидко знайти проблему без дрібного збентеження SEC.

Стільки відповідей і навіть не одна цитата Дійкстри:

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

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

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

Подумайте, ви написали bool IsTestData(string branchCode)функцію.

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

Щоб пройти всі ці тести, вам доведеться додати функцію перевірки параметрів.

Навіть якщо ви лише тестуєте на "хороші" дані 001 -> 999, не замислюючись про можливість 10A, перевірка параметрів змусить вас переписати функцію, коли ви почнете використовувати буквено-цифрові знаки, щоб уникнути винятків, які вона викине