Шукаємо тематичні дослідження, як TDD покращив якість та / або швидкість розвитку [закрито]

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

Дослідження 4-х проектів у IBM та Microsoft. Опубліковано в журналі Emperical Software Engineering .

Емпіричні дослідження показують, що тестова розробка покращує якість

Документ, вперше опублікований у журналі "Емпіричний програмний інженерій програмного забезпечення", повідомляє: "Здається, TDD застосовується в різних областях і може значно зменшити щільність дефектів розробленого програмного забезпечення без значного зниження продуктивності команди розробників". У дослідженні порівняно 4 проекти Microsoft та IBM, які використовували TDD з аналогічними проектами, які не використовували TDD ...

Документ включає в себе 1 тематичне дослідження в IBM та 3 в Microsoft. У кожному конкретному прикладі порівнюються дві команди, що працюють над одним продуктом, використовуючи однакові мови розробки та технології, під одним і тим же менеджером вищого рівня, лише одна з яких використовувала тестові розробки (TDD). Жодна з команд не знала, що вони будуть частиною дослідження протягом циклів їх розвитку. Дослідження випадку IBM стежило за командами, які займалися розробкою драйверів пристроїв. За справами Microsoft слідкували команди, що працюють у Windows, MSN та Visual Studio.

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

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

Однозначно перевірте це: TDD доведено ефективно! Або це?

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

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

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

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

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

У автора є багато хороших моментів щодо того, що TDD не є настільки ефективним (imo, незважаючи на те, що його загрожує смертю)

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

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

як зазначив Андрес Ф, ви можете отримати ці переваги лише за допомогою автоматизованого тестування, не обов'язково TDD - однак TDD вимагає автоматизованих тестів замість того, щоб бути поміркованими або приємними для роботи

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

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

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

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

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

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

• Виявлення помилок на ранній стадії.
• Написання кращого коду, навіть не усвідомлюючи цього.
• Ваш код тепер є більш ретельним, оскільки завдяки вашому тестуванню все відбувається невеликими шматками (у нас були функції, які були 300-400 ліній) нерозумно. Зараз макс 30 і все непомітно перевірено.

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

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

Зазвичай я роблю такі дії:

• Я тримаю свої випробування дуже короткими
• Лише 1 ствердження. Ні руської рулетки.
• Я перевіряю позитивний -негативний та винятковий сценарій

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

Я сподіваюся, що це допомагає