т написання автоматичних тестів (програмний код, написаний спеціально для того, щоб тестувати логіку іншого програмного коду). Особлива увага приділяється двом різновидам тестування:
юніт-тестування модулів;
функціональне тестування.
Розробник не може бути впевнений у правильності написаного ним коду до тих пір, поки не спрацюють абсолютно всі тести модулів розроблюваної ним системи. Тести модулів (юніт-тести) дозволяють розробникам переконатися в тому, що кожен з них окремо працює коректно. Вони також допомагають іншим розробникам зрозуміти, навіщо потрібен той чи інший фрагмент коду, і як він функціонує - в ході вивчення коду тестів логіка роботи тестованого коду стає зрозумілою, оскільки видно, як він повинен використовуватися. Тести модулів також дозволяють розробнику без будь-яких побоювань виконувати рефакторинг (refactoring).
Функціональні тести призначені для тестування функціонування логіки, утвореною взаємодією декількох (часто - досить значного розміру) частин. Вони менш детальні, ніж юніт-тести, але покривають набагато більше - тобто, у тестів, які при своєму виконанні зачіпають більший обсяг коду, шанс віднайти якусь некоректну поведінку, очевидно, більше. З цієї причини в промисловому програмуванні написання функціональних тестів нерідко має більший пріоритет, ніж написання юніт-тестів.
Для XP більш пріоритетним є підхід, званий TDD (від англ. test-driven development - розробка через тестування). Відповідно до цього підходу спочатку пишеться тест, який спочатку не проходить (так як логіки, яку він повинен перевіряти, ще просто не існує), потім реалізується логіка, необхідна для того, щоб тест пройшов. TDD, в деякому розумінні, дозволяє писати код, більш зручний у використанні - тому що при написанні тесту, коли логіки ще немає, найпростіше подбати про зручність майбутньої системи.
Гра в планування.
Основна мета гри в планування - швидко сформувати приблизний план роботи і постійно оновлювати його в міру того, як умови задачі стають все більш чіткими. Артефактами гри в планування є набір паперових карток, на яких записані побажання замовника (customer stories), і приблизний план роботи з випуску наступних однієї або декількох невеликих версій продукту. Критичним фактором, завдяки якому такий стиль планування виявляється ефективною, є те, що в даному випадку замовник відповідає за прийняття бізнес-рішень, а команда розробників відповідає за прийняття технічних рішень. Якщо не виконується це правило, весь процес розпадається на частини.
Замовник завжди поруч.
«Замовник» в XP - це не той, хто оплачує рахунки, а кінцевий користувач програмного продукту. XP стверджує, що замовник повинен бути весь час на зв'язку і доступний для питань.
Парне програмування.
Парне програмування припускає, що весь код створюється парами програмістів, що працюють за одним комп'ютером. Один з них працює безпосередньо з текстом програми, інший переглядає його роботу і стежить за загальною картиною відбувається. При необхідності клавіатура вільно передається від одного до іншого. Протягом роботи над проектом пари не фіксовані: рекомендується їх перемішувати, щоб кожен програміст в команді мав гарне уявлення про всю систему. Таким чином, парне програмування посилює взаємодію всередині команди.
Безперервна інтеграція.
Якщо виконувати інтеграцію розроблюваної системи досить часто, то можна уникнути більшої частини пов'язаних з цим проблем. У традиційних методиках інтеграція, як правило, виконується в самому кінці роботи над продуктом, коли вважається, що всі складові частини розроблюваної системи повністю готові. В XP інтеграція коду всієї системи виконується кілька разів на день, після того, як розробники переконалися в тому, що всі тести модулів коректно спрацьовують.
Рефакторинг.
Рефакторинг (refactoring) - це методика поліпшення коду без зміни його функціональності. XP увазі, що одного разу написаний код в процесі роботи над проектом майже напевно буде неодноразово перероблений. Розробники XP безжально переробляють написаний раніше код для того, щоб поліпшити його. Цей процес називається рефакторингом. Відсутність тестового покриття провокує відмова від рефакторинга у зв'язку з боязню поламати систему, що призводить до поступової деградації коду.
Часті невеликі релізи.
Версії (releases) продукту повинні надходити в експлуатацію якомога частіше. Робота над кожною версією повинна займати якомога менше часу. При цьому кожна версія повинна бути досить осмисленої з погляду корисності для бізнесу.
Чим раніше випускається перша робоча версія прод...
