Device Emulation and Breakpoints

Responsive web applications behave differently at phone, tablet, and desktop sizes, and your tests should cover those differences. Device emulation lets you do this without any physical hardware: the recorder browser renders your application at the selected device's resolution and user-agent, and you record and play back at that resolution just as you do at desktop. Combined with Element Instances for breakpoint-specific identification, a single set of logic can cover your application across all its breakpoints.

Selecting a Device

Open the Device Configuration dialog from the device icon in the recorder header, next to the URL bar. It offers three settings:

1. Recorder Browser Type. Chrome or Edge as the engine for the session.
2. Device Simulation. The resolution to render at. The default is Default Desktop (1366x768); presets cover common Android phones and tablets, iPhones, and iPads; or create your own with + New Device.
3. Custom Web Driver Profile. Advanced browser configuration, covered in Advanced Configuration and Troubleshooting.

Click Proceed and the recorder browser launches with your selection.

When a non-default device is active, an orange dot appears on the device icon in the header, so you always know the recorder is not at desktop resolution.

Creating Custom Devices

A custom device specifies width, height, device pixel ratio, and user-agent string. When creating one, you can start from the standard devices defined in the Chrome browser, or copy one of your existing custom devices and adjust it.

Devices are managed centrally in Resources > Emulated Devices, where anyone on the team can view, create, edit, or delete device definitions. Devices defined here are available both in the recorder and as Device options in the Run modal for formal executions, so you record and execute against the same definitions.

Element Instances for Breakpoints

At different resolutions, the same control can have a genuinely different structure in the page: a full menu at desktop collapses into a hamburger at phone width. Element Instances handle this: one logical element in the repository carries breakpoint-specific identification, and ACCELQ picks the right instance for the resolution the test runs at. Your logic just says "Sign In Button" everywhere.

ACCELQ supports three breakpoint categories for web Element Instances: Desktop, Tablet, and Phone.

Creating a Breakpoint Instance

1. In Device Simulation, select an emulated device in the target breakpoint (say, a phone).
2. Load your application; it renders at that resolution.
3. Right-click the element and choose Save As from the ELEMENT popover.
4. Select the existing logical element from the repository. ACCELQ saves the identification as an instance for that breakpoint.

During execution, the system automatically selects the instance matching the device type the test runs on. Nothing changes in your statements.

When Behavior Differs, Not Just Structure

Element Instances cover identification differences. If your application behaves functionally differently at a breakpoint (a step that exists only on phone, for example), branch with conditional logic instead: type "Is resolution" in the Logic Editor to find the commands for checking the current device resolution.