Що таке одиничне тестування?

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

Види одиничного тестування

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

1) Тестування вручну

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

2) Автоматизоване тестування

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

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

Чому тестування блоку важливо?

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

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

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

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

Тепер скажімо, у вас є код, який має дві частини

  1. Розрахуйте складні відсотки.
  2. Додайте відсотки до основної суми та обчисліть виплату на виплату.

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

  1. Це може бути в розрахунку відсотків.
  2. Це може бути у застосуванні складної логіки.
  3. Це може бути додатково відсотком до основної суми.

Дивіться, як це збільшує зусилля зараз. Усього цього можна було б уникнути, якби обидва компоненти коду були протестовані.

Чому тестування блоку важливо?

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

Інша сторона монети

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

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

Інструменти тестування блоку

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

JUnit

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

NUnit

NUnit - це .Net, як JUnit - для Java. Він має всі важливі особливості JUnit, але для розвитку в мові програмування .Net. Він також підтримує паралельне виконання тестів.

PHPUnit

Подібно до JUnit та NUnit, PHPUnit - це інструмент для розробників PHP. Він також підтримує всі елементарні особливості хорошого інструменту тестування.

XUnit

Інший фреймворк, який є більш загальним, ніж його аналоги, - це XUnit. Він підтримує декілька мов, таких як C ++, C #, ASP.Net тощо. Він також має подібні функції, ніж інші інструменти, доступні на ринку.

Jtest

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

КВІТ

Дуже популярний фреймворк тестування блоку JavaScript. Він може перевірити код JavaScript як на стороні клієнта, так і на стороні сервера.

Жасмін

Ще один дуже широко використовуваний інструмент тестування для фреймворків JavaScript. Він має основну підтримку спільноти Angular, React тощо.

JMockIt

JMockIt - це інструмент з відкритим кодом, який також підтримує знущання над викликами API із синтаксисом запису та підтвердження.

Приклад тестового прикладу

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

public class PhoneValidator
(
public bool IsPhoneValid(string phone)
(
/* write some code to verify if the phone is valid or not. return true, if the phone is valid. return false, if invalid. */
)
)

Тепер нам потрібно протестувати цей фрагмент коду.

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

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

public void TestPhoneValidator()
(
string validPhone = "(123) 456-7890";
string invalidPhone = "123 45"
PhoneValidator validator = new PhoneValidator();
Assert.IsTrue(validator.IsPhoneValid(valid phone));
Assert.IsFalse(validator.IsPhoneValid(invalidPhone));
)

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

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

Поради щодо тестування блоку

  1. Завжди використовуйте інструмент або рамки, що підтримують вашу мову. Інструменти полегшують розробку тестових приладів. Інакше ви можете докласти додаткових зусиль.
  2. Хоча це рекомендується для всього, іноді зручно пропускати прості коди, які безпосередньо не впливають на поведінку системи. Наприклад, коди геттера та сетера можуть бути менш зосереджені на цьому.
  3. Ніколи не пропускайте коди, які безпосередньо впливають на систему або мають вирішальне значення для впровадження бізнес-логіки.
  4. Використовуйте тестові дані, що нагадують виробничі дані.
  5. Ізолюйте свій код. Якщо ваш код залежить від даних із бази даних, не пишіть тестовий виклик для виклику бази даних та отримання значень. Натомість створіть інтерфейс та знущайтесь над API та дзвінками до бази даних.
  6. Перш ніж виправити помилку, що виникає в результаті тестування одиниць, напишіть тестовий випадок, який виявляє дефект. Для цього є три причини:
    • Ви зможете зловити дефекти регресії, що виникають у результаті виправлення.
    • Ваш тестовий випадок тепер є всеосяжнішим.
    • Часто розробник лінується оновлювати свої тестові випадки після написання.
  7. Крім написання тестових випадків, які підтверджують ділову логіку, пишіть і випадки, які перевіряють продуктивність вашого коду. Особливо, коли коди включають циклічність, продуктивність є найбільш впливовою зоною.

Що потрібно пам’ятати

  1. Приклади тестових підрозділів повинні бути незалежними від
    • Код, який підлягає тестуванню. Будь-яка зміна коду не повинна вимагати змін у тестовому випадку, якщо сама бізнес-логіка не зміниться. Наприклад, якщо логіка вимагає, щоб дійсний номер телефону завжди починався з "+", тестовий випадок пристрою потрібно змінити, інакше ні.
    • Інший код - Не повинно бути ніякої взаємодії або залежності з будь-яким іншим кодом або значенням бази даних чи будь-яким подібним. Під час тестування пристрій повинен бути ізольованим.
  2. Дотримуйтесь чітких і послідовних угод про іменування для своїх тестових випадків. Це полегшує відстеження сценаріїв. Ви також можете використовувати засоби контролю версій для відстеження ваших тестових випадків.
  3. Ніколи не передайте свій код на наступний етап, поки це не буде зроблено, помилки виправлені та повторно перевірені.
  4. Найголовніше - зробити це звичкою. Це практика кодування, яку потрібно ввести. Чим більше ви кодуєте без тестування одиниць, тим більше схильний ваш код.

Кар'єра в одиничному тестуванні

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

Висновок

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

Рекомендовані статті

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

  1. Тестування питань інтерв'ю
  2. Застосування веб-тестування
  3. Життєвий цикл дефектів при тестуванні програмного забезпечення
  4. Кар'єра в тестуванні програмного забезпечення
  5. Список рамок тестування для Java