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

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

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

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

Якщо у вас немає тестів, як ви знаєте, що працює ваш код?

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

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

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

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

Ні, це не "необхідно"

У принципах Agile нічого не говорять безпосередньо про тестування.

Але це дуже доцільно

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

Винятки (як зазначає Йорг W Міттаг) включають доказово правильні засоби розробки, системи метапрограмування, що генерують код, та ін. Але такі системи є рідкісними.

І Agile, і XP намагаються уникнути великого дизайну . У BDUF вимоги зібрані, формальна специфікація створюється, то кодування виконується, то тестування буде зроблено. Це має сенс для чітко визначених систем, важливих для життєдіяльності та життєдіяльності, таких як медичне обладнання, космічні зонди тощо.

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

Автоматизовані тестові одиниці швидко записуються, швидко виконуються і дуже модульні / нерозбірні. Це робить їх швидким способом формально вказати та перевірити вимоги.