Чи справді TDD працює для складних проектів?

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

• Генерування та підтримка макетних даних

Підтримувати великі макетні дані важко і нереально. Ще складніше, коли структура бази даних зазнає змін.

• Тестування GUI

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

• Тестування бізнесу

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

• Суперечність вимогам

Насправді важко охопити всі вимоги, що стосуються аналізу та проектування. Багато разів одні вимоги до примітки призводять до суперечності, оскільки проект складний. Суперечність виявляється пізно на етапі впровадження. TDD вимагає, щоб вимоги були на 100% правильними. У таких випадках можна очікувати, що під час створення тестів будуть враховані суперечливі вимоги. Але проблема полягає в тому, що це не так у складних сценаріях.

Я прочитав це запитання: Чому працює TDD?

Чи справді TDD працює для складних корпоративних проектів, або практично обмежується типом проекту?

Підтримувати великі макетні дані важко і нереально. Ще складніше, коли структура бази даних зазнає змін.

Помилковий.

Тестування блоку не вимагає "великих" макетних даних. Для тестування сценаріїв потрібні достатньо глузливих даних і нічого більше.

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

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

Коли продукт розвивається, електронні таблиці тестових випадків оновлюються та створюються нові тестові одиниці. Робіть це постійно. Це справді працює.

Навіть з MVVM та можливістю перевірити GUI, для відтворення сценарію GUI потрібно багато коду.

Що? "Відтворити"?

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

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

Це може бути правдою.

Однак, попросити експертів з тематики надати основні тестові приклади у простій формі (як електронна таблиця) справді допомагає.

Електронні таблиці можуть стати досить великими. Але це добре, оскільки я використовував простий скрипт Python для перетворення електронних таблиць у тестові випадки.

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

Однак. Коли користувачі повідомили про "помилки", я просто запитав, який тестовий випадок у електронній таблиці був неправильним.

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

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

TDD вимагає, щоб вимоги були на 100% правильними. У таких випадках можна очікувати, що під час створення тестів будуть враховані суперечливі вимоги. Але проблема в тому, що це не так у складному сценарії.

Не використання TDD абсолютно зобов’язує, щоб вимоги були 100% правильними. Деякі стверджують, що TDD може терпіти неповні та мінливі вимоги, коли не-TDD підхід не може працювати з неповними вимогами.

Якщо ви не використовуєте TDD, суперечність виявляється пізно на етапі впровадження.

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

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

Так

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

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

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

Після випуску 1.0, оскільки корпорація захотіла швидко змінити сферу застосування через вимоги клієнтів, вони сказали нам, щоб кинути робити TDD, і зняли вимогу про те, що проходять одиничні тести. Дивно було, як швидко якість спустилася в туалет, а потім графік дотримувався цього.

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

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

b) Ви можете змінювати шматочки та шматочки та бачити, як система реагує, оскільки ви весь час будували ковдру тестового покриття.

в) Готовий код буде набагато кращим.

Чи справді TDD працює для складних проектів?
Так. Не кожен проект, тому, як мені кажуть, добре працює з TDD, але більшість бізнес-додатків чудово підходять, і я ставлю на облік ті, які не працюють добре, коли вони написані чисто TDD-манером, можуть бути написані ATDD без великих проблем.

Генерування та підтримка макетних даних
Тримайте це мало і мати лише те, що вам потрібно, і це не страшне питання, як здається. Не зрозумійте мене неправильно, це біль. Але це варто.

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

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

TDD вимагає, щоб вимоги були на 100% правильними.
Ні, це не так. Звідки ви взяли цю ідею? Усі практики Agile приймають, що вимоги змінюються. Вам потрібно знати, що ви робите, перш ніж це зробити, але це не те саме, що вимагати 100% вимог. TDD є звичайною практикою в Scrum, де вимоги (Історії користувачів), за власним визначенням, не є на 100% виконаними.

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

Підтримувати великі макетні дані важко і нереально.

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

Ще складніше, коли структура бази даних зазнає змін.

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

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

Ви маєте рацію, протестувати графічний інтерфейс (View) непросто, і багато людей справляються без нього (до того ж тестування GUI не є частиною TDD). Навпаки, тестування пристрою Controller / Presenter / ViewModel / будь-якого проміжного шару настійно рекомендується, насправді це одна з основних причин таких моделей, як MVC або MVVM.

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

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

TDD вимагає, щоб вимоги були на 100% правильними.

Абсолютно ні. Успішне програмне забезпечення вимагає, щоб вимоги були на 100% правильними;) Тести одиниць просто відображають те, яким є ваше бачення вимог на даний момент; якщо зір є недосконалим, ваш код і програмне забезпечення будуть занадто, одиничні тести чи ні ... І ось одиничні тести блищать: маючи чіткі чіткі заголовки тестів, ваші проектні рішення та інтерпретація вимог стають прозорими, що полегшує вказівку ваш палець на те, що потрібно змінити наступного разу, коли ваш клієнт скаже, "це правило бізнесу не зовсім так, як я хотів би".

Мені слід сміятися, коли я чую, що хтось скаржиться, що причина, що вони не можуть використовувати TDD для перевірки своєї програми, полягає в тому, що їх застосування настільки складна. Яка альтернатива? У тестових мавп стукали по десятках клавіатур? Нехай користувачі будуть тестерами? Що ще? Звичайно, це важко і складно. Як ви думаєте, Intel не перевіряє свої фішки, поки вони не поставляться? Наскільки це "голова в піску"?

Я виявив, що TDD (і тестування одиниць взагалі) практично неможливі з пов'язаних причин: Складні, нові та / або нечіткі алгоритми. Питання, з яким я стикаюсь у більшості дослідницьких прототипів, - це те, що я не маю уявлення, що таке правильна відповідь, крім запуску коду. Це занадто складно, щоб розумно розібратися вручну за будь-якими, окрім смішно тривіальних випадків. Особливо це стосується, якщо алгоритм передбачає евристику, наближення чи недетермінізм. Я все ще намагаюсь перевірити функціональність нижчого рівня, від якого залежить цей код, і застосовувати наполегливі вимоги як перевірку здорового стану. Моя остання методика тестування - це написати дві різні реалізації, в ідеалі двома різними мовами, використовуючи два різних набори бібліотек та порівняти результати.

> Does TDD really work for complex projects?

З мого досвіду: Так для Unittests (перевірка модулів / функцій ізольовано), оскільки в основному вони не мають проблем, про які ви згадуєте: (Gui, Mvvm, Business-Modell). Я ніколи не мав більше, ніж 3 макети / заглушки, щоб заповнити один тест (але, можливо, для вашого домену потрібно більше).

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

Але принаймні деякі проблеми можна зменшити .

> However complex business logic is hard to test since the number 
> of combinations of tests (test space) is very large.

Це справедливо, якщо ви хочете виконати повне висвітлення на рівні інтеграції-тесту або тестування. Можливо, буде простіше зробити повне покриття на рівні одиничного тесту.

Приклад: Перевірка складних прав користувачів

Тестування функції IsAllowedToEditCusterData()на рівні інтеграції-тесту вимагає запитувати у різних об'єктів інформацію про користувача, домен, клієнта, оточення .....

Знущання над цими частинами досить складні. Особливо це актуально, якщо IsAllowedToEditCusterData()доведеться знати ці різні об'єкти.

На рівні Unittest ви мали б функцію, IsAllowedToEditCusterData()яка приймає, наприклад, 20 параметрів, які містять усе, що функція повинна знати. Оскільки IsAllowedToEditCusterData()не потрібно знати, які поля a user, a domain, a customer, .... має це легко перевірити.

Коли мені довелося реалізувати, у IsAllowedToEditCusterData()мене було два перевантаження:

Одне перевантаження, яке не має нічого іншого, ніж отримання цих 20 параметрів, а потім виклик перевантаження 20 параметрами, що робить прийняття рішення.

(у мене IsAllowedToEditCusterData()було лише 5 параметрів, і мені було потрібно 32 різні комбінації, щоб перевірити його повністю)

Приклад

// method used by businesslogic
// difficuilt to test because you have to construct
// many dependant objects for the test
public boolean IsAllowedToEditCusterData() {
    Employee employee = getCurrentEmployee();
    Department employeeDepartment = employee.getDepartment();
    Customer customer = getCustomer();
    Shop shop = customer.getShop();

    // many more objects where the permittions depend on

    return IsAllowedToEditCusterData(
            employee.getAge(),
            employeeDepartment.getName(),
            shop.getName(),
            ...
        );
}

// method used by junittests
// much more easy to test because only primitives
// and no internal state is needed
public static boolean IsAllowedToEditCusterData(
        int employeeAge,
        String employeeDepartmentName,
        String shopName,
        ... ) 
{
    boolean isAllowed; 
    // logic goes here

    return isAllowed;
}

Сумна відповідь - ніщо насправді не працює для великих складних проектів!

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

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

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

За допомогою тестів кожен впевнено може сказати: "Я вніс кардинальні зміни, але всі тести все ще проходять". За визначенням він нічого не зламав. Це призводить до більш гнучких проектів, які можуть розвиватися. Можливо, однією з причин, що нам досі потрібні люди, щоб підтримувати COBOL, є те, що з тих пір тестування не було популярним: P

Я бачив, що великий складний проект повністю провалювався, коли TDD використовувався виключно, тобто, принаймні, не встановлювався в налагоджувачі / IDE. Дані про макет та / або тести виявились недостатніми. Реальні дані клієнтів Beta були чутливими і їх неможливо було скопіювати або записати. Таким чином, команда розробників ніколи не змогла виправити фатальні помилки, які виявлялися, коли вказували на реальні дані, і весь проект був знятий, всі звільнені, цілий шматочок.

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

Отже, як і все, головний баланс. TDD може бути хорошим, але не покладайтеся на нього виключно.

Я так думаю, см Test Driven Development дійсно працює

У 2008 році Начіаппан Нагаппан, Е. Майкл Максимілієн, Тірумалеш Бхат та Лорі Вільямс написали документ під назвою «Усвідомлення покращення якості за рахунок тестового розвитку: результати та досвід чотирьох промислових команд» (PDF-посилання). Реферат:

Тестова розробка (TDD) - це практика розробки програмного забезпечення, яка спорадично використовується десятиліттями. З цією практикою інженер-програмний інженер циклічно переходить цикл між написанням невдалих тестів одиниці та написанням коду реалізації, щоб пройти ці тести. Нещодавно тестова розробка знову постала як важлива умова для практичних методів розробки програмного забезпечення. Однак мало емпіричних доказів підтверджує або спростовує корисність цієї практики в промисловому контексті. Тематичні дослідження проводилися з трьома командами розробників у Microsoft та однією в IBM, які прийняли TDD. Результати тематичних досліджень показують, що щільність дефектів перед випуском чотирьох продуктів знизилася між 40% і 90% щодо аналогічних проектів, які не застосовували практику TDD. Суб'єктивно,

У 2012 році практики розробки Ruby on Rails припускають TDD. Я особисто покладаюся на такі інструменти, як rspec для написання тестів та макетів, factory_girl для створення об’єктів, capybara для автоматизації браузера, simplecov для покриття коду та захист для автоматизації цих тестів.

В результаті використання цієї методології та цих інструментів я схильний суб'єктивно погоджуватися з Нагаппаном та ін ...

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

Можливо, вимоги складні і мінливі, інфраструктура нестабільна, команда молодша і з високим оборотом, або архітектор - ідіот.

Для проекту TDD симптом цього майбутнього провалу полягає в тому, що тести не можуть бути записані за графіком; ви намагаєтеся лише дізнатися, «що триватиме так довго, а у нас тільки це ».

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

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