Тестування пов’язаного списку додатки управління освітленням в Visual C # (Sharp)

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

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

Так як клас BaseLinkedList оголошений абстрактним, для нього вимагається реалізуються Метою реалізації є надати нам достатньо інформації про стоянні і контексті обєкта У такому випадку нам потрібно визначити обєкт, котий зможе протестувати кожну складову класу BaseLinkedList Тестовий клас можна порівняти з манекеном для тестування автомобілів на міцність при аваріях, з прикріпленими до нього купою датчиків і йдуть від них провідників Далі наводиться проста реалізація класу в проекті TestLightingSystem Не забудьте вставити посилання на LibLightingSystem (клацніть правою кнопкою по пункту References у проекті TestLightingSystem і виберіть послідовність команд Add Reference | Projects | LibLightingSystem)

using LibLightingSystem namespace TestLightingSystem

{

class Linkedltem : BaseLinkedList { private string _identifier

public Linkedltem(string identifier) {

_identifier = identifier

}

public string Identifier { get {

return _identifier

}

}

public override string ToStringO { string buffer

buffer = &quotthis(&quot + .identifier + &quot)" if (Next = null) {

buffer += &quot next(&quot + ((Linkedltem)Next)Identifier + &quot)"

}

else {

buffer += &quot next(null)"

}

if (Prev = null) {

buffer += &quot prev(&quot + ((Linkedltem)Prev)Identifier + &quot)"

}

else {

buffer += &quot prev(null)"

}

return buffer

}

}

}

У класі Linkedltem оголошений ТІЛЬКИ ОДИН член даних, . identifier, який використовується для ідентифікації примірника Тестовий код викликає методи insert () і Remove (), після чого генерує наочне уявлення повязаного списку У разі якщо щось не так, наочне уявлення застосовується для ПСКА джерела проблеми Ми не будемо писати тести для наочно представлені, т к це занадто ускладнить тестування

Для створення наочного уявлення обєкта використовується перевантаження методу Tostring () За замовчуванням всі обєкти мають реалізацію Tostr ing (), уся робота якої полягає в наданні ідентифікатора посилання обєкта Щоб змусити метод Tostring про робити що-небудь корисне, його потрібно перевантажити У прикладі метод Tostring про створює буфер, що містить ідентифікатор обєкта BaseLinkedList і ідентифікатори наступного і попереднього обєктів Ці три ідентифікатора надають інформацію про структуру повязаного списку

Наступним кроком є ​​написання тесту у файлі Programcs проекту TestLightingSystem, який перевіряє, працює ЧИ метод Inserto, як требуея Даний тест виглядає таким чином:

namespace TestLightingSystem

{

class Program

{

static void Main(string[] args)

{

Testlnsert()

}

public static void Testlnsert() { ConsoleWriteLine(&quot**************&quot) ConsoleWriteLine(&quotTestlnsert: Start&quot) Linkedltem iteml = new Linkedltem(&quotiteml&quot) Linkedltem item2 = new Linkedltem(&quotitem2&quot) Linkedltem item3 = new Linkedltem(&quotitem3&quot) string tostring = itemlTostring() ConsoleWriteLine(tostring)

if (itemlNext =null || itemlPrev =null) { throw new Exception(

&quotTestlnsert: Empty structure is incorrect&quot)

}

itemlInsert(item2) toString = itemlToStringO ConsoleWriteLine(toString)

if ((itemlNext == item2 &amp&amp itemlPrev == null)) { throw new Exception(

&quotTestlnsert: Iteml-&gtItem2 structure is incorrect&quot)

}

toString = item2ToString() ConsoleWriteLine(toString)

if ((item2Next == null &amp&amp item2Prev == iteml)) { throw new Exception(

&quotTestlnsert: Item2-&gtIteml structure is incorrect&quot)

}

item2Insert(items) toString = item2ToString() ConsoleWriteLine(toString)

if ((item2Prev == iteml &amp&amp item2Next == items)) { throw new Exception(

&quotTestlnsert: Item2-&gtIteml, Item3 structure is incorrect&quot)

}

toString = items ToStringO ConsoleWriteLine(toString)

if ((itemsPrev == item2 &amp&amp itemsNext == null)) { throw new Exception(

&quotTestlnsert: Item3-&gtItem2, structure is incorrect&quot)

}

toString = itemlToString() ConsoleWriteLine(toString)  toString = item2ToString() ConsoleWriteLine(toString)  toString = item3ToString() ConsoleWriteLine(toString) ConsoleWriteLine(&quotTestlnsert: End&quot)

}

}

}

Результати тесту виглядають таким чином:

**************

Testlnsert: Start

this(iteml) next(null) prev(null) this(iteml) next(item2) prev(null) this(item2) next(null) prev(iteml) this(item2) next(item3) prev(iteml) this(item3) next(null) prev(item2) this(iteml) next(item2) prev(null) this(item2) next(item3) prev(iteml) this(item3) next(null) prev(item2) Testlnsert: End

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

У методі Testlnsert () виникає ситуація, коли створюються три екземпляри класу Linkeditem: itemi, item2 і item3 Первоначальн про пов і тр і елемент а не повязані, але за допомогою методу insert () ми повязуємо їх у структуру (рис 84)

Рис 84 Тестируемая структура двонаправленого повязаного списку

Але щоб отримати структуру, показану на рис 84, потрібно виконати кілька проміжних кроків, які тестуються в реалізації методу Testlnsert () На кожному кроці виконується перевірка на правильність значень властивостей Next і prev кожного елемента Якщо деякі значення не збігаються, то видається виняток, яке вказує неправильну структуру У разі виключив набуває важливість генерування наочної структури До речі, при разротке алгоритмів для методів insert () і Remove () наочні структури допомогли мені обчислити джерело помилки

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

ІНСТРУМЕНТИ ДЛЯ ТЕСТУВАННЯ І НАЛАГОДЖЕННЯ

Деякі можуть думати, що для того щоб обчислити причину невдалого тесту, нбходімо застосувати відладчик Але якщо тести розроблені належним чином, преняются як частина всеохоплюючої інфраструктури тестування і видають пообную інформацію про результати тестування, то потреба в відладчик зменшується Програмісти, які сповідують розробку TDD (Test-Driven Develop-ment, розробка, керована тестами), включаючи мене, ставлять під питання користь, принесену отладчиком Згідно статті Test-Driven Development у Вікіпедії (http://enwikipediaorg/wiki/Test-driven_development):     Програмісти, практикуючи чисту розробку TDD, кажуть, що вони рідко відчувають необхідність прегать до отладчику Спільно з використанням системи управління версіями, при неуспішному тестуванні, повернення до останньої версії, що успішно пройшла всі тести, майже завжди більш ефективно, ніж налагодження .

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

Говорячи про створення тестів, як було сказано в чолі 6,їх написання можна значельно полегшити, застосовуючи інфраструктури для тестування, такі як NUnit (http://wwwnunitorg) або Microsoft Visual Studio Team System (http://msdn2microsoftcom/ en-us/vstudio/defaultaspx) При розробці комерційного коду, ви, швидше за все, будете використовувати одну з таких інфраструктур Хоча самі по собі ці інфртруктури не пропонують прямої допомоги в написанні тестів, вони надають утиліти для генерування і протоколювання помилок і відображення прогресу тестів Не вірте рекламним заявам, що стверджують, що їхні інструменти можуть самі створювати тести Ніякої інструмент не може створювати тести, т к для цього йому потрібно було б розуміти контекст тестованого коду А так як таких інструмеов в даний час не існує, то вам доведеться створювати власні тести

Джерело: Гросс К С # 2008: Пер з англ – СПб: БХВ-Петербург, 2009 – 576 е: ил – (Самовчитель)

Схожі статті:


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

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*