Émulation Mobile dans Playwright: Tests Responsifs et Tactiles

L'émulation mobile de Playwright simule le viewport, le ratio de pixels et le user agent d'un appareil. Elle active aussi les événements tactiles pour tester des configurations iPhone et Android sans matériel réel.

Ce que l'émulation mobile fait (et ne fait pas)

L'émulation Playwright simule :

• Les dimensions du viewport
• Le ratio de pixels de l'appareil (écrans Retina)
• La chaîne user agent
• Les événements tactiles (remplace les événements souris)
• La géolocalisation (optionnel)
• La locale et le fuseau horaire (optionnel)

Elle ne teste pas :

• Les performances réelles de l'appareil
• Les vrais moteurs de navigateurs mobiles (vous restez sur Chromium, Firefox ou WebKit)
• Le rendu spécifique au matériel
• Les applications mobiles natives

Pour les tests sur vrais appareils, vous avez besoin de services comme BrowserStack ou Sauce Labs. L'émulation couvre le besoin le plus courant : vérifier que votre application se comporte correctement aux dimensions d'un viewport mobile et répond aux interactions tactiles.

Utiliser les presets d'appareils intégrés

Playwright inclut une bibliothèque de presets d'appareils. Utilisez-les dans votre config :

// playwright.config.ts
import { defineConfig, devices } from '@playwright/test';

export default defineConfig({
  projects: [
    {
      name: 'chromium-desktop',
      use: { ...devices['Desktop Chrome'] },
    },
    {
      name: 'mobile-chrome',
      use: { ...devices['Pixel 7'] },
    },
    {
      name: 'mobile-safari',
      use: { ...devices['iPhone 14'] },
    },
    {
      name: 'tablette',
      use: { ...devices['iPad Pro 11'] },
    },
  ],
});

Lancer uniquement les tests mobiles :

npx playwright test --project=mobile-chrome

Voir tous les appareils disponibles :

npx playwright --list-devices

La liste inclut environ 80 presets : appareils Pixel, iPhones, téléphones Galaxy, iPads, tablettes Surface.

Émulation d'appareil par test

Surchargez l'émulation pour un seul test sans modifier la config :

import { test, expect, devices } from '@playwright/test';

test('la navigation mobile fonctionne', async ({ browser }) => {
  const context = await browser.newContext({
    ...devices['iPhone 14'],
  });
  const page = await context.newPage();

  await page.goto('/');
  // Le menu hamburger doit être visible sur mobile
  await expect(page.getByRole('button', { name: 'Menu' })).toBeVisible();
  await page.getByRole('button', { name: 'Menu' }).click();
  await expect(page.getByRole('navigation')).toBeVisible();

  await context.close();
});

Événements tactiles

Sur les appareils mobiles, Playwright utilise des événements tactiles au lieu des événements souris. La plupart des interactions fonctionnent de façon identique (click(), fill(), type() se traduisent tous correctement). Là où le tactile compte :

// Tap (identique à click sur mobile)
await page.getByRole('button').tap();

// Geste de balayage
await page.touchscreen.tap(100, 200);

Pour les carrousels à balayage, le pull-to-refresh ou les gestes complexes, vous aurez peut-être besoin de page.evaluate() pour déclencher des événements tactiles personnalisés. La plupart des interactions mobiles simples fonctionnent avec les méthodes de locators standard.

Tester le comportement responsive

Le cas d'usage le plus pratique : vérifier votre mise en page à différents breakpoints.

test.describe('mise en page responsive', () => {
  test('desktop affiche la nav complète', async ({ page }) => {
    await page.setViewportSize({ width: 1280, height: 720 });
    await page.goto('/');
    await expect(page.getByRole('navigation')).toBeVisible();
    await expect(page.getByRole('button', { name: 'Menu' })).not.toBeVisible();
  });

  test('mobile affiche le hamburger', async ({ page }) => {
    await page.setViewportSize({ width: 375, height: 812 });
    await page.goto('/');
    await expect(page.getByRole('button', { name: 'Menu' })).toBeVisible();
    await expect(page.getByRole('navigation')).not.toBeVisible();
  });
});

Viewport vs configuration use

// Viewport uniquement — ne change pas le user agent ni les événements tactiles
await page.setViewportSize({ width: 375, height: 812 });

// Émulation complète — viewport + user agent + tactile + ratio de pixels
const context = await browser.newContext({
  viewport: { width: 390, height: 844 },
  userAgent: 'Mozilla/5.0 (iPhone; CPU iPhone OS 16_0 like Mac OS X)...',
  deviceScaleFactor: 3,
  isMobile: true,
  hasTouch: true,
});

Pour les tests responsive qui vérifient uniquement la mise en page, setViewportSize convient. Pour les tests qui vérifient un comportement spécifique au mobile (événements tactiles, CSS mobile, sniffing du user agent), utilisez l'émulation complète via les presets devices.

Comparaison de captures d'écran pour les tests responsive

La régression visuelle est particulièrement utile sur mobile : les bugs de mise en page sont souvent invisibles dans les assertions de test mais évidents sur une capture d'écran.

test('la page d\'accueil mobile correspond à la baseline', async ({ page }) => {
  await page.setViewportSize({ width: 375, height: 812 });
  await page.goto('/');
  await expect(page).toHaveScreenshot('mobile-homepage.png', {
    fullPage: true,
  });
});

Lancez une fois pour générer la baseline. Les exécutions suivantes comparent avec elle. Un décalage de mise en page d'un seul pixel fait échouer le test.

Ce qu'il faut tester spécifiquement sur mobile

Tous les tests n'ont pas besoin d'une version mobile. Priorités :

• Navigation (menus hamburger, tiroirs mobiles)
• Formulaires (le clavier virtuel ne couvre pas le bouton de soumission, les zones tactiles sont assez grandes)
• Tableaux (scroll horizontal vs mise en page empilée)
• Images (srcset responsive, pas de débordement)
• Flux de paiement (chemin critique, boutons adaptés au tactile)
• Modales (contenu défilable, bouton de fermeture accessible)

Ignorez les tests mobiles pour les tableaux de bord admin qui ne supportent pas le mobile, les tests qui vérifient un comportement identique quel que soit le viewport, et les tests API ou tests unitaires.