SpecFlowMaster: як покращити якість тестів

Робимо правильні речі
Сучасна розробка не може існувати без автоматизованих тестів. Тести можуть бути написані дуже швидко навіть непрофесіоналами. Отже, маємо тести, все начебто добре. Чи можемо ми покластись на такі тести? Яка якість наших інструментів перевірки якості? Давайте подивимось на SpecFlow тести, які можуть бути написані людською мовою.

Feature: SpecFlowFeature
	In order to avoid silly mistakes
	As a math idiot
	I want to be told the sum of two numbers

Scenario: Add two numbers
	Given I have entered 50 into the calculator
	And I have entered 70 into the calculator
	When I press add
	Then the result should be 120 on the screen

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

Feature: SpecFlowFeature
	In order to avoid silly mistakes
	As a math idiot
	I want to be told the sum of two numbers

Scenario: Add two numbers
	Given I have entered 50 into the calculator
	And I have entered 70 into the calculator
	When I press add
	And I press memorize
	Then the result should be 120 on the screen

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

Такий тип тестів може з’явитись в результаті великого рефакторінгу або суттєвих змін в технічне завдання. Це означає, що ми все ще будемо мати всі тести зеленими, але вони перевірять систему не достатньо добре. Тест вказаний вище може буде виправлений двома способами: видалити цей доданий крок «And I press memorize» або додати ще один крок в кінці тесту для перевірки стану пам’яті «Then value stored in memory is 120».

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

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

Технічні примітки
1. C#, VB
2. SpecFlow 3.0 або вище
3. .NET Framework 4.7.1 або вище, .NET Core 2.0 або вище

Що планується зробити пізніше
1. Підтримка До (Before) та Після (After) атрибутів
2. Схожі плагіни для Java та Node.js

Посилання
1. Плагін може бути знайдений на гітхаб github.com/pavlobcn/SpecFlowMaster
2. Будь-які відгуки висилайте на arskiev@gmail.com

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Особливо весело буде, коли таке на продакшені пустити. Видалив «заради тесту» якесь finally, залишив транзакцію відкритою — ай, весело!

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

Якщо «класичні» тести не змінюють нічого глобального, то вони і не тестують нічого глобального. Не мають потенційної шкоди лише ті тести, що не мають і суттєвої вигоди.

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

Железобетонный аргумент. Скажи ещё «ты дурак», сразу +20 к ЧСВ

Аргумент на что?

Якщо «класичні» тести не змінюють нічого глобального, то вони і не тестують нічого глобального.
Не мають потенційної шкоди лише ті тести, що не мають і суттєвої вигоди.

на «это»? Т.е. ^это по-твоему аргументы? Ты сам не предоставил ничего, поэтому я просто заметил что это полнейший бред.

думаю это было апелированию что тестируя на моках ты больше тестируешь моки а не систему

Так действительно же бред был.
Вообще, у меня такое впечатление, что ты сам это мутационное тестирование применяешь к местным собеседникам:) как шандарахнешь чем-нибудь заведомо нелепым и смотришь, что будет. Иначе я такие сообщения от тебя не могу объяснить :)

Ну кто пускает такую рандомизацию на продакшен, тот ССЗБ. А в тестовом горшочке это нормальный подход, мутационное тестирование — уже древняя почтенная технология, пишут, ещё в 71-м придумали (хотя наверняка и раньше).
Мы используем частичные аналоги такого, помечая явно места для инверсий. Может, когда-нибудь руки дойдут и до такой автоматизации...

Подписаться на комментарии