10. előadás: mobil automatizálás appiummal

Mobile Testing Overview

Introduction to Mobile Testing

• The session begins with an introduction to the topic of mobile testing, noting that a previous seminar was missed and this will be addressed now.

• The speaker mentions two upcoming presentations, one focusing on test development, which will be discussed later depending on progress with the current topic.

Software Development Cycle

• Discussion about the software development cycle emphasizes the need for rollback capabilities when issues arise during development.

• The speaker introduces Appium as a tool for testing mobile applications, highlighting its architecture and similarities to Selenium.

Understanding Appium Architecture

Key Features of Appium

• Appium uses a protocol similar to that of Selenium, allowing for consistent communication between TestScript and NodeJS server.

• The architecture is based on Appium 2.0, which includes new plugins not present in earlier versions; these plugins enhance functionality.

Client Libraries and Communication

• Various client libraries are available for different programming languages (e.g., Python, PHP, Rust), enabling flexibility in writing tests.

• The test client communicates with the Appium server via REST API; this server can run manually or automatically within code.

Interacting with Mobile Devices

Device Interaction Mechanisms

• When interacting with real devices or emulators, specific options must be set due to platform dependencies.

• Focus is primarily on Android testing due to the absence of iOS devices; however, minimal adjustments can allow for cross-platform compatibility.

Challenges in Mobile Development

• Discusses challenges related to permissions and security controls inherent in mobile operating systems compared to traditional PCs.

Understanding Mobile Application Testing

Challenges in Web Application Communication

• The speaker discusses the limitations of web applications running in different tabs, emphasizing that communication between them is not straightforward and requires navigating complex security measures.

• It is noted that browsers operate under a sandbox model, isolating applications from each other, which complicates interactions compared to mobile devices where this isolation is less stringent.

Differences Between Android and iOS Development

• The speaker highlights the distinct philosophies of Android and iOS regarding application development and debugging, indicating that developers need to understand these differences for effective testing.

• Android provides tools like debug options within Android Studio, allowing developers elevated access to interact with their applications during development.

Accessibility Features in Mobile Platforms

• The discussion includes the importance of accessibility features on mobile platforms, noting that they allow users with disabilities to control applications effectively.

• The speaker mentions an API on Android designed for writing applications that cater to accessibility needs, which can be leveraged for testing purposes.

UI Testing Frameworks

• iOS has its own UI testing framework provided by Apple, specifically designed for conducting UI tests on iPhones. This framework differs from Android's approach but serves a similar purpose.

• Understanding both frameworks is crucial as they require configuration before use; however, the underlying principles remain consistent across platforms.

Evolution of Testing Tools

• The speaker reflects on advancements since previous presentations about Appium 1.0, highlighting new plugins that simplify native app automation tasks such as loading apps or simulating clicks.

• There are challenges associated with unit testing due to the need for comprehensive data collection (e.g., CPU usage or memory consumption), which was previously lacking in infrastructure.

Customization and Logging in Tests

• Emphasis is placed on logging events during tests to capture exceptions or errors meaningfully rather than relying solely on manual processes.

• Plugins have been developed to enhance Appium's functionality by allowing customization of test actions and logging capabilities based on specific requirements.

Setting Up Local Test Environments

• A brief overview of setting up a local environment for running tests using Node.js (NOGS), including installation steps necessary for utilizing Appium effectively.

Overview of Automation Frameworks and Tools

Discussion on Platform Compatibility

• The architecture discussed operates on a similar protocol as Selenium, allowing for testing on both web and desktop applications.

• While it is possible to integrate web tests into the automation framework, the current focus does not prioritize this approach.

Installation of Drivers

• Two NPM commands are highlighted for installing necessary drivers, including the UI Automator driver for Android testing.

• The process involves specifying which driver to use from available sources like npm or NuGet.

Testing Framework Options

• A table summarizes various platforms suitable for automation; mobile platforms are emphasized with options beyond just UI Automator.

• Espresso is introduced as an alternative framework that may offer faster performance but lacks some capabilities compared to UI Automator.

Accessing System Features

• UI Automator provides extensive access to system functions and data through Android's API, making it powerful yet complex.

• Espresso is simpler and effective for standard application testing without requiring advanced features.

SDK Requirements

• To run tests effectively, users must have the Android SDK installed via tools like Android Studio or Visual Studio.

• Both frameworks rely on accessibility features present in mobile platforms, which differ significantly from web environments where such features are less common.

Understanding Automation Logic

• The automation relies on operating system permissions to interact with applications, enabling detailed test execution based on user interactions.

• In contrast to Android's approach, iOS has dedicated testing frameworks integrated within its SDK rather than relying solely on general-purpose tools.

Web Protocol Communication

• A deeper dive into the wire protocols used in web automation reveals how devices communicate during testing processes.

Session Management and Automation in Mobile Testing

Understanding Sessions

• A session is crucial for managing the lifecycle of an automation process, starting at the beginning of a test and allowing navigation within that context.

• The ability to execute custom commands during a session is essential for plugins to function properly, enabling actions not inherently part of the app framework.

Executing Commands

• During automation, screenshots can be requested while in a session, along with file uploads and other functionalities.

• The WebDriver protocol outlines various endpoints; however, some may not be relevant for mobile testing (e.g., double-click actions).

Setting Up Automation

• To run code on a mobile device, two applications must be installed: specifically, the Appium-related APK on Android devices.

• The Android Debug Bridge (ADB) is necessary for communication between the host machine and Android devices in debug mode.

Features of ADB

• ADB facilitates connection options via USB or Wi-Fi but does not support Bluetooth connections.

• It allows running Linux-based commands on Android devices due to their Linux foundation.

Application Management through ADB

• ADB enables installation and removal of applications directly from the connected device, which is vital for UI Automator functionality.

• Applications installed via ADB can receive commands from the Appium server when granted elevated permissions.

Logging and Port Forwarding

• Accessing logs from an Android device through ADB is important for development purposes; it helps monitor application behavior.

Android Debug Bridge (ADB) Overview

Understanding ADB and Its Functions

• ADB allows communication with an Android device via a local host, utilizing port forwarding to facilitate this connection.

• ADB can perform various functions, including rebooting the device through command-line instructions provided by the Android SDK.

• The adb devices command lists connected devices, while shell commands can be executed for file transfers and log access.

• ADB supports both USB and IP connections; automatic recognition typically occurs when using USB.

• It is essential for debugging applications, providing access to hidden features of the Android operating system when developer mode is enabled.

Key Features of ADB

• Access to restricted areas of the Android OS requires enabling developer options and granting permissions on the device.

• The primary purpose of ADB is to facilitate debugging processes during app development.

• Appium utilizes ADB for executing commands necessary for running tests on Android devices.

Appium Integration with ADB

Application Installation Process

• Two applications are installed on the device: UI Automator 2 and another APK that monitors instrumentation data.

• UI Automator 2 serves as a server facilitating communication between Appium and the device through port forwarding.

• The second APK ensures proper functioning of the automation server by monitoring its performance.

Test Execution Workflow

• Upon starting Appium on a machine, it automatically installs required applications on the connected device before initiating tests.

• The first component activated is the Android JUnit Runner, which interacts with installed applications during testing phases.

Communication Flow in Testing

Steps in Test Execution

• After launching test APK, UI Automator server starts listening for incoming commands over a local socket connection.

• Commands received are forwarded from Appium's server to UI Automator driver, which executes them on the device effectively.

Summary of Framework Structure

Automation Process Overview

Introduction to Automation and Communication

• The automation server communicates through a specific APK, allowing commands to be issued and processed effectively.

• Utilizes UI automation linked to the operating system, specifically Android, facilitating command execution on mobile devices.

• This basic automation workflow has been in existence since around 2011, marking a significant development in app automation.

Plugins and Customization

• Recent advancements include plugins that allow for customization of workflows beyond basic commands.

• Initial endpoints provided limited control; however, more complex workflows necessitated additional functionalities.

• Developers began creating wrappers and workflows leading to the integration of custom code into the infrastructure via plugins.

Technical Aspects of Plugins

• Plugins are built as Node.js components, enabling developers to extend existing functionalities without altering the core codebase.

• The primary goal is to modify or enhance existing functions without direct access to the application’s codebase.

Functionality Extensions

• Extensions can introduce new commands not present in the WebDriver protocol while modifications may involve slight adjustments or complete overrides of existing functions.

• There is no technical distinction between modification and overriding; both serve similar purposes but vary in implementation effort.

Historical Context and Development Challenges

• Previously, making changes required forking the original project (Appium), which led to conflicts with updates from the main repository.

• New developments could create compatibility issues with customized versions of Appium due to ongoing changes from its community-driven nature.

Creating New Endpoints

Importance of New Commands

• One major motivation behind plugin development was the ability to create new commands or endpoints within an existing server framework.

Endpoint Configuration

• Developers can define new endpoints by writing components that integrate seamlessly with their Appium server setup.

• This allows for dynamic interaction where newly defined endpoints can handle requests independently from standard ones.

Modifying Existing Endpoints

Modifying Command Lifecycles in Appium

Overview of Command Lifecycle Modification

• The protocol allows for a quasi-overwrite capability, enabling modifications to existing commands.

• Discusses the lifecycle of commands when the Appium server interacts with mobile devices, highlighting various events such as application startup and command execution.

• Existing commands can be modified by subscribing to event handlers, allowing actions based on user interactions like button clicks or message box closures.

Event Handling and Action Control

• It is possible to intervene at multiple points within the command lifecycle, including preventing actions under certain conditions (e.g., disabling a button click).

• When starting the Appium server on a mobile device, custom code can be injected into both the startup and shutdown processes of the test server.

Database Management During Testing

• Custom code can manage local databases during unit tests; for instance, saving data before shutting down the test server.

• Emphasizes that during startup and shutdown processes of the test server, there are opportunities to inject necessary operations related to database management.

Plugin Development Insights

• There are numerous existing plugins available for enhancing functionality; new plugin development is not uncommon but should build upon established solutions.

• A list of plugins was requested from GPT; some may be outdated or irrelevant due to changes in technology.

Synchronization Challenges in Mobile Automation

• Unlike web automation where asynchronous behavior complicates interactions, mobile automation typically operates synchronously—actions complete before returning control.

• However, background communications (e.g., waiting for data from servers while displaying spinners) necessitate careful handling of synchronization issues.

Waiting Mechanisms in Mobile Applications

• The "wait" plugin is designed to handle scenarios where elements appear after certain conditions are met (e.g., waiting for a login button).

• The Appium Dashboard previously provided insights into device status but has been integrated into the Appium Device Farm.

Integration with Device Farms

Device Farm Overview

Introduction to Device Farm

• The speaker introduces a web application that provides a dashboard for monitoring connected devices, enhancing the testing process.

• Emphasizes the importance of building frameworks for testing across multiple devices and platforms rather than running tests locally.

Plugins and Tools

• Mentions various plugins such as the Express Router Plugin and Appium Flutter Driver, which enhance testing capabilities for specific environments like Flutter.

• Discusses the purpose of device farms in facilitating tests across different devices, highlighting its utility in managing multiple test scenarios.

Functionality of Device Farms

• Describes how device farms allow users to view connected devices through a web interface, showcasing their status and available functionalities.

• Users can interact with devices directly from the dashboard, including viewing screenshots and managing test sessions.

Monitoring Test Sessions

• Explains how users can monitor ongoing test sessions, including details about builds deployed on various devices and their respective outcomes.

• Highlights session management as a key concept in web driver functionality, allowing detailed tracking of commands executed during tests.

Infrastructure Considerations

• Discusses setting up local infrastructures with an Appium server connected to multiple mobile devices via Wi-Fi instead of USB connections.

• Cautions against setting up extensive hardware without strong justification; suggests exploring rental services for physical testing resources next week.

Conclusion on Device Farms

• Indicates that many services built around device farms operate on similar principles, providing access to physical devices for comprehensive testing without needing to purchase them all.

Using Plugins in Appium: A Detailed Overview

Introduction to Plugin Usage

• The discussion begins with the necessity of specifying a plugin during server startup, indicating that plugins are essential for enhancing functionality.

• The speaker emphasizes the importance of selecting the correct plugin, specifically mentioning an "element wage" plugin and its role in executing commands on the server.

Functionality and Command Integration

• Depending on the actions performed by the plugin, new commands can be added to enhance server capabilities, particularly for waiting on elements or endpoints.

• The integration of custom commands into existing frameworks is highlighted, noting that these commands must be invoked correctly within the testing environment.

Challenges with Language Bindings

• A significant issue arises from the lack of language bindings for many useful plugins; developers cannot directly use certain commands in their unit test code.

• The absence of packages (e.g., NuGet packages) for these plugins complicates their usage within standard coding practices.

Custom Command Invocation

• When a custom command appears, it often requires writing additional wrapper code to facilitate its invocation due to missing language support.

• Developers need to create helper classes that interact with WebDriver instances while defining strategies and selectors for element identification.

Element Selection Strategies

• Various strategies can be employed when waiting for elements, including fixed time waits or exponential backoff methods.

• Specific selectors must be defined based on UI element attributes (like IDs or XPath), which dictate how elements are targeted during tests.

Timeout Management and Error Handling

• Timeouts are crucial; if an expected element does not appear within a specified duration, errors will occur. This necessitates robust error handling mechanisms.

• All additional commands introduced by plugins run through an execute script command on the driver, which may lead to challenges if scripts fail without clear feedback.

Logging and Debugging Complex Commands

• If a script fails due to incorrect input structures or unrecognized methods, minimal feedback is provided. This highlights the need for comprehensive logging alongside command execution.

• Complicated workflows involving multiple parameters require careful validation since failures may not return meaningful error messages.

Understanding Plugin Development and Lifecycle in APIUM

Overview of Plugin Functionality

• The effectiveness of a plugin is often determined by its performance in various contexts, indicating that it may not be designed with object-oriented principles.

• Custom plugins can function correctly while others fail, suggesting the need for thorough testing across multiple unit tests to ensure stability.

• Running plugins typically requires execution through an endpoint service, highlighting the importance of understanding how to utilize these endpoints effectively.

Event Handling and Lifecycle Modifications

• The discussion shifts towards potential enhancements in functionality, focusing on modifying existing behaviors within the APIUM server lifecycle.

• Two primary hooks are identified: on start and on stop, which trigger during the APIUM server's startup and shutdown rather than the application being tested.

Session Management Hooks

• Initialization and cleanup code can be executed at server startup or shutdown using these hooks, similar to setup methods in other frameworks like NUnit.

• Session-related hooks include session start, which activates when a session begins, allowing operations based on session ID parameters.

Capabilities During Sessions

• The on session init hook runs before a session is created, providing an opportunity to prepare for upcoming actions.

• Default capabilities are established upon session creation; if additional permissions are required (e.g., taking screenshots), they must be handled appropriately during this phase.

Command Handling Lifecycle

Command Invocation and Hook Management

Command Arguments and Dispatcher Setup

• The discussion begins with the importance of defining command arguments for invocation, emphasizing that checks should ideally occur within the command itself rather than externally.

• Mention of router hooks that allow new endpoints defined by plugins to be registered as URL endpoints on the APIUM server, which need to be stored in a dictionary.

• Explanation of how routing can redirect requests from specific URLs to designated commands, facilitating command redirection.

Plugin Development and Event Handling

• Introduction to creating custom plugins as NoJS components that interact with server events, highlighting the necessity for these components to trigger upon specific occurrences.

• A sample code is presented demonstrating how to utilize hooks within server code, specifically focusing on importing base plugins and developing custom functionalities.

Synchronization Requirements

• Emphasis on all methods within plugins needing to be synchronous; caution against introducing side effects that could disrupt expected behaviors in the application.

• Discussion about ensuring correct execution order of events (e.g., on start vs. on session start), stressing that while synchronization is crucial, it does not guarantee sequential execution.

Overview of Testing Framework

• Summary of requirements for testing Android applications locally using a server setup; highlights the complexity involved when scaling up operations requiring DevOps expertise.

Cloud-Based Testing Solutions

Introduction to AppCenter

• Transition into discussing Microsoft's AppCenter as a centralized platform for testing mobile applications, showcasing its capabilities through visual examples found via Google image searches.

Application Configuration and Test Integration

• Description of how users can configure their applications and devices within AppCenter for testing purposes; mentions generating statistics and various metrics from test results.

Pipeline Integration