Відеобібліотека

Знайди точне пояснення

Пошук у нотатках курсу Design Patterns для автоматизаторів з переходом на потрібну секунду.

Python мануфактураJavaDesign Patterns для автоматизаторів

Design Patterns для автоматизаторів · 9:14–15:08

Platform design guidelines і типи застосунків

iOS та Android мають різні звичні navigation patterns, date pickers, системні кнопки й жести. Те, що інтуїтивно для користувача iOS, може бути незрозумілим на Android, тому UI/UX guidelines обох платформ є практичним джерелом тестових очікувань. Розрізняються web, hybrid, cross-platform і native застосунки. Hybrid app поєднує native shell з WebView-екранами, cross-platform app будується на Flutter, React Native чи Xamarin, а native app реалізується окремо під конкретну ОС.

Мобільне тестування та автоматизація →

Design Patterns для автоматизаторів · 0:00–6:36

Одна поведінка для різних платформ

Один business scenario може мати різні UI-кроки на mobile/desktop Web або iOS/Android: відрізняються header, navigation, scrolling, calendar і time picker. Тест при цьому має залишатися спільним за наміром, а platform-specific дії — вибиратися окремо. Strategy пропонується як спосіб сховати ці відмінності за одним interface. Водночас для першого невеликого набору тестів звичайний `if` або `switch` може бути достатнім KISS-рішенням.

2. API. Патерни проєктування або чому огірок нікому не тре. →

Design Patterns для автоматизаторів · 0:00–9:14

Native і cross-platform технології

Flutter і React Native дозволяють розвивати iOS та Android з однієї основної codebase, а native-модулі підключати для Bluetooth, geolocation, notifications чи інших можливостей системи. Це прискорює MVP, але native-застосунки на Swift і Kotlin зазвичай мають менше проміжних шарів і працюють швидше. Навіть у cross-platform продукті команди часто розділяються за iOS/Android або за product streams. Тестувальнику потрібно розуміти специфіку кожної платформи, а не вважати однакову codebase гарантією однакової поведінки.

Мобільне тестування та автоматизація →

Design Patterns для автоматизаторів · 6:36–15:18

Реалізація Strategy і межа її складності

У прикладі пошук системного setting потребує scroll на iOS і іншої взаємодії на Android. `SettingsScreen` вибирає `IosSettings` або `AndroidSettings` за driver/platform і делегує однаковий публічний метод потрібній реалізації. Коли різниться багато screens і їх послідовність, кількість strategies швидко зростає. Для двох повністю native codebases автор інколи віддає перевагу окремим Swift/Kotlin test projects з однаковими test cases: вони ближчі до application code і їх легше запускати розробникам.

2. API. Патерни проєктування або чому огірок нікому не тре. →

Design Patterns для автоматизаторів · 23:22–32:29

Test builds, repositories і feature flags

iOS test builds поширюються через TestFlight, а build/distribution pipeline може використовувати App Center або platform developer consoles. Потрібно розрізняти dev build, прив'язаний до test/stage backend, і production-configured build, який перевіряють перед release. Тестувальнику рекомендовано мати read access до iOS/Android repositories, щоб бачити diff, перемикатися на feature branch і збирати зміни локально через Xcode чи Android Studio. Feature flags дають змогу вмикати функціонал для ролей, оточень або частини користувачів без розриву між backend і mobile releases. **Актуальність станом на 2026-08-08.** Visual Studio App Center завершив роботу 31 березня 2025 року; тимчасове продовження Analytics & Diagnostics закінчилося 30 червня 2026 року. Згадку у відео слід сприймати як історичну, а новий distribution/diagnostics workflow звіряти з актуальними сервісами платформи ([Microsoft Learn](https://learn.microsoft.com/en-us/appcenter/retirement)).

Мобільне тестування та автоматизація →

Design Patterns для автоматизаторів · 1:03:29–1:06:44

Native automation і межі автоматизованого UI

Для native iOS згадується XCUITest, для Android — Espresso з wrapper на кшталт Kaspresso/Kakao, для React Native — Detox, для Flutter — Flutter Driver. Native tools мають коротший шлях до UI й швидше реагують на оновлення екрана. Складні canvas/builders, custom maps і довільна graphics interaction можуть бути дешевшими для ручної перевірки або вимагати окремої testability роботи з розробниками. Форми, списки та типові business flows автоматизуються значно простіше. **Актуальність станом на 2026-08-08.** Для нових Flutter integration tests офіційна документація веде до пакета `integration_test`, а для наявних `flutter_driver` suites дає окремий migration path ([Flutter documentation](https://docs.flutter.dev/release/breaking-changes/flutter-driver-migration)).

Мобільне тестування та автоматизація →

Design Patterns для автоматизаторів · 1:23:41–1:33:02

Scroll, virtualized lists і locator contracts

Mobile list часто рендерить лише елементи, видимі на screen, тому до п'ятого чи наступного item неможливо звернутися без scroll. Це відрізняється від звичайного HTML, де весь отриманий DOM часто вже доступний driver. Для пошуку радять `accessibilityId`, accessibility label, Android resource ID або content description, а не XPath. Тестувальник може сам додавати ці атрибути в application code і надсилати невеликий PR на review, бо hotfixes та custom components регулярно порушують навіть узгоджений locator guideline.

Мобільне тестування та автоматизація →

Design Patterns для автоматизаторів · 2:20:00–2:23:27

Enums і завершальний принцип

Для environment і platform радять використовувати typed enums замість порівняння випадкових strings: `dev`, `stage`, `prod`, `iOS`, `Android`, `Web`. Це дає autocomplete і чітко обмежує допустимі значення. Завершальна думка: Controller, DTO та інші патерни мають залишатися гнучкими й простими. Структура тестів починається з фактичної architecture та поточного contract, а ускладнюється лише коли з'являється відповідна проблема.

2. API. Патерни проєктування або чому огірок нікому не тре. →
Запитати в чаті про «android» →