Студопедия — Тема 7. Розробка через тестування
Студопедия Главная Случайная страница Обратная связь

Разделы: Автомобили Астрономия Биология География Дом и сад Другие языки Другое Информатика История Культура Литература Логика Математика Медицина Металлургия Механика Образование Охрана труда Педагогика Политика Право Психология Религия Риторика Социология Спорт Строительство Технология Туризм Физика Философия Финансы Химия Черчение Экология Экономика Электроника

Тема 7. Розробка через тестування






 

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

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

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

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

Середовище розробки повинно швидко реагувати на невеликі модифікації коду. Архітектура програми повинна базуватися на використанні безлічі сильно зв'язаних компонентів, які слабо зчеплені один з одним, завдяки чому тестування коду спрощується.

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

Зрозуміло, що до тестів застосовуються ті ж вимоги стандартів кодування, що і до основного коду.

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

Наступний крок при РЧТ – запустити усі тести, і подивитись, чи вони пройшли. Це підтверджує, що усі тести працюють коректно, і, що нові тести помилково не проходять, не вимагаючи при цьому ніякого нового коду.

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

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

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

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

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

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

Ідея перевіряти, що тільки написаний тест не проходить, допомагає переконатися, що тест реально щось перевіряє. Тільки після цієї перевірки слід приступати до реалізації нової функціональності. Цей прийом, відомий як «червоний / зелений / рефакторінг». Під червоним тут розуміють тести, які не пройшли, а під зеленим - які пройшли тестування.

Відпрацьовані практики розробки через тестування призвели до створення техніки «розробка через прийомочне тестування», в якому критерії описані замовником автоматизуються в приймальні тести, що використовуються потім в звичайному процесі розробки через модульне тестування. Цей процес дозволяє гарантувати, що додаток задовольняє сформульованим вимогам. При розробці через прийомочне тестування, команда розробників сконцентрована на чіткій задачі: задовольнити приймальні тести, які відображають відповідні вимоги користувача.

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

Дослідження 2005 року показало, що використання розробки через тестування передбачає написання більшої кількості тестів; у свою чергу, програмісти, які пишуть більше тестів, схильні бути більш продуктивними.

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

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

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

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

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

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

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

Головним недоліком РЧТ є те, що до нього тяжко звикнути.

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

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

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

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

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

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

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

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

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

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

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

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

Інтерфейс повинен мати дві реалізації. Перша надає доступ до ресурсу, і друга, що є fake- або mock-об'єктом. Все, що роблять fake-об'єкти, це додають повідомлення виду «Об'єкт person збережений» в лог, щоб потім перевірити правильність поведінки. Mock-об'єкти відрізняються від fake- тим, що самі містять твердження, які перевіряють поведінку тестованого коду. Методи fake- і mock-об'єктів, які повертають дані, можна налаштувати так, щоб вони повертали при тестуванні одні й ті ж правдоподібні дані. Вони можуть емулювати помилки так, щоб код обробки помилок міг бути ретельно протестований. Fake- або mock-реалізації є прикладами впровадження залежності.

Використання fake-і mock-об'єктів для представлення зовнішнього світу призводить до того, що справжня база даних та інший зовнішній код не будуть протестовані в результаті процесу розробки через тестування. Щоб уникнути помилок, необхідні тести реальних реалізацій інтерфейсів, описаних вище. Ці тести можуть бути відокремлені від інших модульних тестів і реально є інтеграційними тестами. Їх необхідно менше, ніж модульних, і вони можуть запускатися рідше. Проте, найчастіше вони реалізуються використовуючи ті ж бібліотеки для тестування, що і модульні тести.

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

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

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

 

 

 







Дата добавления: 2015-10-15; просмотров: 670. Нарушение авторских прав; Мы поможем в написании вашей работы!



Обзор компонентов Multisim Компоненты – это основа любой схемы, это все элементы, из которых она состоит. Multisim оперирует с двумя категориями...

Композиция из абстрактных геометрических фигур Данная композиция состоит из линий, штриховки, абстрактных геометрических форм...

Важнейшие способы обработки и анализа рядов динамики Не во всех случаях эмпирические данные рядов динамики позволяют определить тенденцию изменения явления во времени...

ТЕОРЕТИЧЕСКАЯ МЕХАНИКА Статика является частью теоретической механики, изучающей условия, при ко­торых тело находится под действием заданной системы сил...

Выработка навыка зеркального письма (динамический стереотип) Цель работы: Проследить особенности образования любого навыка (динамического стереотипа) на примере выработки навыка зеркального письма...

Словарная работа в детском саду Словарная работа в детском саду — это планомерное расширение активного словаря детей за счет незнакомых или трудных слов, которое идет одновременно с ознакомлением с окружающей действительностью, воспитанием правильного отношения к окружающему...

Правила наложения мягкой бинтовой повязки 1. Во время наложения повязки больному (раненому) следует придать удобное положение: он должен удобно сидеть или лежать...

Гидравлический расчёт трубопроводов Пример 3.4. Вентиляционная труба d=0,1м (100 мм) имеет длину l=100 м. Определить давление, которое должен развивать вентилятор, если расход воздуха, подаваемый по трубе, . Давление на выходе . Местных сопротивлений по пути не имеется. Температура...

Огоньки» в основной период В основной период смены могут проводиться три вида «огоньков»: «огонек-анализ», тематический «огонек» и «конфликтный» огонек...

Упражнение Джеффа. Это список вопросов или утверждений, отвечая на которые участник может раскрыть свой внутренний мир перед другими участниками и узнать о других участниках больше...

Studopedia.info - Студопедия - 2014-2024 год . (0.013 сек.) русская версия | украинская версия