Migration des Tests d'API de Postman vers Playwright

La fixture request de Playwright donne un client HTTP complet dans le même dépôt, le même test runner et le même pipeline CI. Il en fait un remplacement pratique des collections Postman dans les suites de régression.

La traduction conceptuelle

| Concept Postman | Équivalent Playwright |

|---|---|

| Collection | Fichier de test |

| Requête | request.get(), request.post(), etc. |

| Script de pré-requête | Hook beforeEach ou setup de fixture |

| Script de test (pm.test) | Assertions expect() |

| Variable d'environnement | process.env.VARIABLE |

| Variable de collection | Fixture de test ou constante partagée |

| Authorization → Bearer Token | Header dans request.post({ headers: { Authorization: ... } }) |

| Newman (runner CLI) | npx playwright test |

Votre premier test Postman réécrit en Playwright

Postman :

// POST {{baseUrl}}/auth/login
// Body: { "email": "{{email}}", "password": "{{password}}" }
// Onglet Tests :
pm.test("Statut est 200", function() {
    pm.response.to.have.status(200);
});
pm.test("Retourne un token", function() {
    const body = pm.response.json();
    pm.expect(body.token).to.be.a('string');
    pm.environment.set("authToken", body.token);
});

Playwright :

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

test('la connexion retourne un token d\'auth', async ({ request }) => {
  const response = await request.post(`${process.env.BASE_URL}/auth/login`, {
    data: {
      email: process.env.TEST_EMAIL,
      password: process.env.TEST_PASSWORD,
    },
  });

  expect(response.status()).toBe(200);

  const body = await response.json();
  expect(typeof body.token).toBe('string');
  expect(body.token.length).toBeGreaterThan(0);
});

Plus propre. Versionné. Sans dépendance cloud.

Partager le token d'auth entre les tests

Dans Postman, on définit une variable d'environnement dans un test et on l'utilise dans le suivant. Dans Playwright, on utilise une fixture ou un setup global.

Approche 1 : setup global (pour toute la suite)

// global-setup.ts
import { request } from '@playwright/test';
import fs from 'fs';

export default async function globalSetup() {
  const ctx = await request.newContext();
  const response = await ctx.post(`${process.env.BASE_URL}/auth/login`, {
    data: {
      email: process.env.TEST_EMAIL,
      password: process.env.TEST_PASSWORD,
    },
  });
  const { token } = await response.json();

  // Sauvegarder pour les tests
  process.env.AUTH_TOKEN = token;
  await ctx.dispose();
}

Approche 2 : fixture d'auth (par test)

// fixtures/auth.ts
import { test as base, APIRequestContext } from '@playwright/test';

type AuthFixtures = {
  authedRequest: APIRequestContext;
  authToken: string;
};

export const test = base.extend<AuthFixtures>({
  authToken: async ({ request }, use) => {
    const response = await request.post('/auth/login', {
      data: {
        email: process.env.TEST_EMAIL!,
        password: process.env.TEST_PASSWORD!,
      },
    });
    const { token } = await response.json();
    await use(token);
  },

  authedRequest: async ({ playwright, authToken }, use) => {
    const context = await playwright.request.newContext({
      baseURL: process.env.BASE_URL,
      extraHTTPHeaders: {
        Authorization: `Bearer ${authToken}`,
      },
    });
    await use(context);
    await context.dispose();
  },
});

Tests :

import { test } from '../fixtures/auth';
import { expect } from '@playwright/test';

test('récupérer le profil utilisateur (authentifié)', async ({ authedRequest }) => {
  const response = await authedRequest.get('/user/profile');
  expect(response.status()).toBe(200);

  const user = await response.json();
  expect(user.email).toBeDefined();
});

Migrer des collections Postman

Pour les grandes collections Postman, voici la stratégie de migration.

1. Exportez votre collection en JSON depuis Postman

2. Identifiez les chemins critiques : toutes les requêtes Postman n'ont pas besoin de devenir des tests Playwright. Concentrez-vous sur celles que vous exécutez en régression.

3. Traduisez requête par requête, en commençant par les plus simples (requêtes GET, sans auth)

4. Regroupez par ressource : un fichier par domaine API (users.spec.ts, orders.spec.ts, payments.spec.ts)

N'essayez pas de traduire automatiquement. Le modèle de scripting de Postman ne correspond pas proprement à Playwright, et la traduction mécanique produit des tests illisibles. Réécrivez-les.

Ce que Postman fait mieux

Postman conserve des avantages pour certains workflows.

Tests exploratoires : l'interface de Postman est plus rapide pour les requêtes ponctuelles en cours de développement. Pas besoin d'écrire de code pour essayer un endpoint. Documentation : les collections Postman peuvent générer de la documentation API. Les tests Playwright ne le font pas. Collaboration avec les non-codeurs : un chef de produit ou un développeur peu à l'aise avec le code peut utiliser Postman.

La répartition pratique : Postman pour explorer et documenter les APIs pendant le développement. Playwright pour les suites de régression qui tournent en CI. Ils se complètent.

Exécuter les tests API en CI

Une fois les tests migrés vers Playwright, la CI est simple : identique à n'importe quelle suite Playwright.

# .github/workflows/api-tests.yml
jobs:
  api-tests:
    runs-on: ubuntu-latest
    env:
      BASE_URL: ${{ vars.STAGING_URL }}
      TEST_EMAIL: ${{ secrets.TEST_EMAIL }}
      TEST_PASSWORD: ${{ secrets.TEST_PASSWORD }}
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm ci
      - run: npx playwright test tests/api/

Pas de Newman. Pas de cloud Postman. Pas de plan payant pour la CI. Juste npx playwright test.