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

Розрахунки в моєму коді добре перевірені, але, оскільки так багато GUI-коду, загальне покриття коду нижче, ніж я хотів би. Чи є якісь вказівки щодо одиничного тестування GUI-коду? Це навіть має сенс?

Наприклад, у моєму додатку є графіки. Я не зміг зрозуміти, як автоматизувати тестування графіків. Потрібне людське око, AFAIK, щоб перевірити правильність графіка.

(Я використовую Java Swing)

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

Звичайно, відповідь - використовувати MVC та перемістити якомога більше логіки з графічного інтерфейсу.

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

Ви можете спробувати UISpec4J - це функціональна бібліотека з відкритим кодом та / або бібліотека тестування одиниць для додатків Java на базі Swing ...

Існує Selenium RC , який автоматизує тестування веб-інтерфейсу. Він буде записувати дії та відтворювати їх. Вам все одно потрібно буде пройти взаємодію з вашим інтерфейсом, тому це не допоможе в охопленні, але його можна використовувати для автоматизованих збірок.

Ви можете спробувати використовувати огірок та свінгер для написання функціональних тестів на прийняття простою англійською мовою для додатків Swing GUI. Свінгер використовує бібліотеку Джеммі Netbeans під кришкою для керування додатком.

Огірок дозволяє писати такі тести:

 Scenario: Dialog manipulation
    Given the frame "SwingSet" is visible
    When I click the menu "File/About"
    Then I should see the dialog "About Swing!"
    When I click the button "OK"
    Then I should not see the dialog "About Swing!"

Подивіться цю демонстрацію відео Свінгера, щоб побачити її в дії.

Ось кілька порад:

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

Для графіки слід перевірити значення, яке ви надаєте коду, який генерує графіку.

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

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

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

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

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

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

Підвіконня для вікон для гойдалок та Ajax

Мій підхід до тестування GUI розвивається, як і галузевий консенсус. Але я думаю, що кілька ключових прийомів починають з'являтися.

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

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

2. Блок тестування. Ви пишете тести на функції або невеликі одиниці поведінки GUI. Наприклад, вашим графікам може знадобитися обчислити різні відтінки кольору на основі "базового" кольору. Ви можете витягнути цей обчислення у функцію і написати для неї тест одиниці. Ви можете шукати таку логіку в графічному інтерфейсі (особливо логічну для повторного використання) та витягувати її в стримані функції, які можна легше перевірити. Навіть складну поведінку можна витягнути і перевірити таким чином - наприклад, послідовність кроків майстра може бути вилучена до функції, а тестова одиниця може перевірити, що за умови введення повертається правильний крок.

3. Провідник компонентів. Ви створюєте екран "explorer", єдиною ролю якого є демонстрація кожного з повторно використовуваних компонентів, що складають ваш графічний інтерфейс. Цей екран дає вам швидкий та простий спосіб візуально перевірити, чи має кожен компонент правильний вигляд. Провідник компонентів є більш ефективним, ніж вручну переглядати всю вашу програму, тому що A) вам потрібно лише один раз перевірити кожен компонент, і B) вам не доведеться переходити вглиб програми, щоб побачити компонент, ви можете просто переглянути і перевірити це негайно.

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

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

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

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

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

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

Все це базується на моєму особистому досвіді і дослідженнях, а також велику запис-вгору на тестах UI по Ham Vocke .

З того, що я знаю, це досить складно, і це дійсно залежить від мови - численні мови мають свій спосіб тестування графічного інтерфейсу, але якщо вам дійсно потрібно тестувати графічний інтерфейс (на відміну від взаємодії модель / gui), вам часто доводиться імітувати фактичні користувачі натискання кнопок. Наприклад, SWT-фреймворк, що використовується в Eclipse, забезпечує SWTBot , JFCUnit вже згадувалося, у Mozilla є власний спосіб імітації цього в XUL (і з того, що я читав у їхніх блогах, ці тести здаються досить крихкими).

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

Якщо ви використовуєте Swing, FEST-Swing корисний для керування вашим графічним інтерфейсом та тестування тверджень. Це дозволяє досить просто перевірити речі на кшталт "якщо я натискаю кнопку A, слід відобразити діалогове вікно B" або "якщо я виберіть варіант 2 зі спадного меню, усі прапорці повинні знятись" .

Графічний сценарій, який ви згадуєте, не так легко перевірити. Отримати покриття коду для компонентів GUI досить просто, створивши та відобразивши їх (і, можливо, керуючи ними за допомогою FEST). Однак висловлювання змістовних тверджень є важкою частиною (і висвітлення коду без змістовних тверджень - це вправа на самообман). Як ви перевіряєте, що графік не був намальований вниз головою або занадто малий?

Я думаю, що ви просто повинні визнати, що деякі аспекти GUI не можуть бути ефективно перевірені автоматизованими тестами одиниць і що вам доведеться протестувати їх іншими способами.

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