Як можна TDD для помилки, яку можна перевірити лише після її виправлення?


13

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

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

У такій простої функції, як let sum = (a, b) => a - b, наприклад , ви можете написати тест на те, чому sum(1, 2)не дорівнює, 3перш ніж писати будь-який код.

У випадку, який я описую, я не можу перевірити, оскільки не знаю, що таке перевірка (я не знаю, яким має бути твердження).

Рішення описаної проблеми:

let dataTransfer = e.dataTransfer
let canvas = document.createElement('canvas');
canvas.style.opacity = '0';
canvas.style.position = 'absolute';
canvas.style.top = '-1000px';
dataTransfer.effectAllowed = 'none';

document.body.appendChild(canvas);
dataTransfer.setDragImage(canvas, 0, 0);

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

Який би був підхід TDD до цієї проблеми? Чи є написання тесту перед кодом обов'язковим чи необов’язковим?


2
Тоді зробіть свої дослідження. Знайдіть рішення ... потім напишіть свій тест, виправте та рефактор. Тести розраховані не на те, щоб (лише) перевірити, чи працює ваш код, а надалі підтвердити ваше повне рішення. Спочатку ви створюєте тест, щоб не вийшов з ладу, яке властивість ви будете тестувати? Це один спосіб почати.
Хуан Карлос Едуардо Ромаїна Ак

@Kilian Foth: Я бачу ваші добрі наміри, змінивши назву питання, але ваша редакція визнала неправдивими частини моєї відповіді. Більше того, ваш новий титул зробив, що ІМХО не підходить до органу запитань. Тож я зробив відкат, без образи.
Док Браун

Відповіді:


26

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

  • як автоматично перевірити певну поведінку графічного інтерфейсу користувача?

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

Особливо "тест-водіння" дизайн інтерфейсу або вдосконалення інтерфейсу користування автоматичними тестами, записаними заздалегідь, буквально неможливо. Ви "керуєте" дизайном інтерфейсу, вдосконалюючи, показуєте результат людині (собі, деяким тестерам або користувачеві) і запитуєте про зворотний зв'язок.

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


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

1
@esoterik: Так, і всі ці автоматизовані методи чутливі до помилок і крихкі, як я вже писав. Єдиний не крихкий підхід, який я знаю, - це тестування вручну.
Док Браун

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

1
@maximedupre: знайшов цю рекламу для інструменту, який намагається вирішити проблему, але все-таки стаття, здається, взагалі відповідає моїй відповіді.
Док Браун

5

Який би був підхід TDD до цієї проблеми? Чи є написання тесту перед кодом обов'язковим чи необов’язковим?

Один із способів - застосувати аналог розчину шипа .

Джеймс Шор так описав:

Ми виконуємо невеликі, поодинокі експерименти, коли нам потрібна додаткова інформація.

Основна ідея полягає в тому, що ви відкладаєте інструменти дизайну, поки ви з'ясовуєте, що відбувається. Як тільки у вас є підшипники, ви знову підбираєте інструменти для проектування.

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

Коні на курси.

Редагувати:

Як ви можете автоматизувати тест, якщо дефект може побачити лише людське око?

Я хотів би запропонувати трохи інший правопис: "Як ви можете автоматизувати тест, якщо автоматизація тесту не є економічно ефективною?"

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

Існує два способи побудови дизайну програмного забезпечення: Один із способів - зробити його таким простим, що явно немає недоліків - CAR Hoare

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

Для тестування інтеграції наших кодів з реальним кодом третьої сторони ми покладаємось на інші методи (візуальна перевірка, дзвінки з технічної підтримки, оптимізм…).

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


Мені подобається, що Джеймс Шор повинен сказати. В даний час я слідкую за скрінкладом www.letscodejavascript.com і багато чого вчуся. Я прочитаю посилання, на які ви вказали.
maximedupre

Ви маєте рацію, я читав більше про TDD та шипи. Вам потрібно знати, як виглядає код, який ви намагаєтеся перевірити, перш ніж намагатися його перевірити. TDD не може навчити вас нічого, чого ви ще не знаєте, але потенційно він може показати вам деякі речі, які вам потрібно вивчити, перефразовуючи Джеймса Шор. У цій замітці я хочу запропонувати етап TDD: Spike, Test, Fail, Pass, Refactor.
maximedupre

0

Зовсім інша перспектива, тестування навколо інтерфейсу користувача / GUI можна зробити дещо краще стосовно тестування прийнятності (тести, орієнтовані на функціональний / робочий процес).

Що стосується Інтернету, я думаю, що такі рамки, як селен webdriver, мають потенціал наблизитися до правильного тесту, але накладні витрати для початку можуть бути дещо значною, і це зсув потоку, що спостерігається з TDD, щодо просто одиничних тестів .

Частина, яка спеціально допомогла б у вашій ситуації, - це те, що називається Page Object Model ( https://www.guru99.com/page-object-model-pom-page-factory-in-selenium-ultimate-guide.html ). Це досягає явного зіставлення графічного інтерфейсу часу роботи з деяким кодом, або шляхом іменування методів / подій / членів класу.

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

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


Нещодавно я випробовував e2e / функціональні тести (із селеном webdriver) у TDD, але накладні витрати, безумовно, занадто великі, як ви сказали. Ви не можете бути ефективним розробником і робити TDD за допомогою тестів e2e. Я використовував POM, але єдиною перевагою, яку він мені дав, була вдосконалена архітектура моєї тестової кодової бази.
maximedupre

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

0

Як виглядає образ-привид? Якщо ви створили фіктивний інтерфейс одного відомого кольору, куди ви помістили свій перетягується компонент? Чи був би присутнім конкретний колір, якби було зображення привидів.

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

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


Виконано - так. Міцний - залежить. Просто зміна кольору / теми вашого інтерфейсу може порушити ваш тест / і, що для мене не здається надто міцним.
Шон Бертон

1
Ви б не перевіряли весь інтерфейс користувача. Ви б створили фіктивний інтерфейс для компонента drag-n-drop.
Есбен Сков Педерсен

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

Так. Вам доведеться автоматизувати перетягування. Це не буде одиничним тестом, а скоріше тестом e2e.
Есбен Сков Педерсен
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.