Cadre de conception d'applications axé sur l'automatisation et meilleures pratiques

Exemple réel :

// ❌ BAD - No semantic meaning 

<div onClick={() => setSelected(!selected)}> 

<span>Enable notifications</span> 

</div> 

 

// ✅ GOOD - Semantic and testable 

<label htmlFor="notifications-toggle"> 

<input  

id="notifications-toggle"  

type="checkbox"  

data-testid="notifications-toggle" 

/> 

Enable notifications 

</label>

Point de vue du testeur :

Avec le HTML sémantique, je peux utiliser des sélecteurs basés sur les rôles : page.locator('input[role="checkbox"]') ou même getByRole("checkbox", { name: /enable notifications/i }) dans Playwright, ce qui rend les tests plus lisibles et plus résistants aux changements de style.

Implémenter des états d'attente explicites et des indicateurs de chargement

Le problème:

Les applications utilisant beaucoup de JavaScript chargent leur contenu de manière dynamique. Les testeurs rencontrent souvent des problèmes de stabilité car les éléments apparaissent et disparaissent de façon asynchrone, et ils ne savent pas quand la page est réellement « prête ».

Ce que les développeurs devraient faire :

• Utilisez le data-testid pour les états de chargement :

  <div data-testid="loading-spinner"> 

• Marquer les sections de contenu avec des attributs de statut : aria-busy="true" pendant la charge
• Assurez-vous que l'application atteigne un état stable avant de répondre aux interactions des utilisateurs.
• Fournir des signaux explicites de fin de chargement

// ❌ BAD - No semantic meaning 

<div onClick={() => setSelected(!selected)}> 

<span>Enable notifications</span> 

</div> 

 

// ✅ GOOD - Semantic and testable 

<label htmlFor="notifications-toggle"> 

<input  

id="notifications-toggle"  

type="checkbox"  

data-testid="notifications-toggle" 

/> 

Enable notifications 

</label>

// Wait for loading to complete 

await page.locator('[data-testid="loading-spinner"]').waitFor({ state: 'hidden' }); 

 

// Now interact with the list 

const userList = page.locator('[data-testid="user-list"]'); 

await expect(userList).toBeVisible();

Concevoir des formulaires avec une gestion claire des entrées 

Le problème: 

Les formulaires complexes présentant des états d'erreur peu clairs, des validations cachées ou des comportements de saisie non standard perturbent les scripts d'automatisation. 

Ce que les développeurs devraient faire: 

• Utilisez les éléments de formulaire HTML standard avec des attributs de nom clairs. 
• Fournir des messages d'erreur explicites avec data-testid marqueurs 
• S'assurer que la validation du formulaire est observable (et non pas des échecs silencieux). 
• Inclure les confirmations de succès 

Exemple réel: 

// ✅ GOOD - Clear form with observable states 

<form data-testid="login-form"> 

<div> 

<label htmlFor="email-input">Email:</label> 

<input 

id="email-input" 

name="email" 

type="email" 

data-testid="email-input" 

required 

/> 

{errors.email && ( 

<span data-testid="email-error" role="alert"> 

{errors.email} 

</span> 

)} 

</div> 

 

<div> 

<label htmlFor="password-input">Password:</label> 

<input 

id="password-input" 

name="password" 

type="password" 

data-testid="password-input" 

required 

/> 

</div> 

 

<button  

type="submit"  

data-testid="login-submit-button" 

disabled={isSubmitting} 

> 

{isSubmitting ? 'Logging in...' : 'Login'} 

</button> 

 

{submitSuccess && ( 

<div data-testid="login-success-message" role="status"> 

Login successful! Redirecting... 

</div> 

)} 

</form>

Code d'automatisation du testeur (Selenium) :

from selenium import webdriver 

from selenium.webdriver.common.by import By 

from selenium.webdriver.support.ui import WebDriverWait 

from selenium.webdriver.support import expected_conditions as EC 

 

driver = webdriver.Chrome() 

driver.get("https://app.com/login") 

 

# Fill form 

driver.find_element(By.CSS_SELECTOR, '[data-testid="email-input"]').send_keys("test@example.com") 

driver.find_element(By.CSS_SELECTOR, '[data-testid="password-input"]').send_keys("password123") 

 

# Submit 

driver.find_element(By.CSS_SELECTOR, '[data-testid="login-submit-button"]').click() 

 

# Wait for success message 

WebDriverWait(driver, 10).until( 

EC.presence_of_element_located((By.CSS_SELECTOR, '[data-testid="login-success-message"]')) 

)

Rendre les réponses de l'API prévisibles et cohérentes

Le problème:

Les applications mobiles et web qui dépendent des réponses d'API nécessitent des structures de données stables. Des réponses d'API incohérentes ou imprévisibles entraînent des échecs de tests aléatoires.

Ce que les développeurs devraient faire :

• Utilisez une structure JSON cohérente sur tous les points de terminaison.
• Incluez des identifiants uniques (ID) dans chaque objet
• Contrats d'API de documentation (OpenAPI/Swagger)
• Renvoyer des codes d'état HTTP et des messages d'erreur pertinents
• Tester les réponses de l'API pendant le développement

Exemple réel :

// ✅ GOOD - Predictable API response 

{ 

"success": true, 

"data": { 

"id": "user-123", 

"email": "test@example.com", 

"name": "John Doe", 

"created_at": "2026-03-01T10:00:00Z" 

}, 

"timestamp": "2026-03-22T14:30:00Z" 

} 

 

// ❌ BAD - Inconsistent response 

{ 

"status": "ok", 

"user": { 

"uid": "123", 

"email_address": "test@example.com" 

}, 

"meta": { "time": 1679574600 } 

}

Automatisation mobile du testeur (Appium) :

# With predictable API, testers can mock and validate 

from appium import webdriver 

 

driver = webdriver.Remote("http://localhost:4723/wd/hub", capabilities) 

 

# Mock the API response 

mock_response = { 

"success": True, 

"data": { 

"id": "user-123", 

"name": "Test User" 

} 

} 

 

# Now reliably access user data in the app 

user_name_element = driver.find_element("xpath", "//text[@value='Test User']")

Fournir une configuration et des modes adaptés aux tests

Le problème:

Les fonctionnalités de production telles que les outils d'analyse, les publicités, les traqueurs tiers et les délais réseau peuvent interférer avec l'exécution des tests.

Ce que les développeurs devraient faire :

• Indiquez le mode de test ou une variable d'environnement
• Autoriser la désactivation des analyses, des publicités et du suivi dans les environnements de test
• Prise en charge du saut des animations ou délais inutiles
• Fournir des points de terminaison d'API pour réinitialiser l'état de l'application à des fins de test

Exemple concret (React) :

// ✅ GOOD - Test-friendly configuration 

const isTestMode = process.env.REACT_APP_TEST_MODE === 'true'; 

 

function App() { 

return ( 

<div> 

{!isTestMode && <Analytics />} 

{!isTestMode && <Ads />} 

<MainContent /> 

</div> 

); 

}

Variable d'environnement :

REACT_APP_TEST_MODE=true npm start

Attentes en matière d'automatisation des documents

Le problème:

Les testeurs consacrent du temps à analyser en profondeur comment interagir avec une application, notamment avec ses composants personnalisés.

Ce que les développeurs devraient faire :

• Documents data-testid conventions de nommage dans votre fichier README
• Fournir un guide de test/automatisation pour les fonctionnalités complexes
• Documentation du composant partagé (Storybook, etc.)
• Listez tous les événements personnalisés et les rappels que les testeurs doivent connaître.

Exemple de documentation :

## Automation Testing Guide 

 

### Naming Conventions 

- Buttons: `data-testid="[feature]-[action]-button"` (e.g., `user-logout-button`) 

- Form inputs: `data-testid="[form]-[field]-input"` (e.g., `login-email-input`) 

- Lists: `data-testid="[list]-container"` and items as `[list]-item-[id]` 

 

### Key Components 

- **Modal**: `.modal-overlay` (hidden when closed), contains `data-testid="modal-close-button"` 

- **Dropdown**: Use semantic `<select>` or `aria-haspopup="listbox"` 

- **Date Picker**: Supports keyboard navigation and `aria-label` 

 

### Test Environment Setup 

Set `API_URL=http://localhost:3001/api` to use mock server

Points clés à retenir pour les développeurs

Conclusion

Créer des applications prêtes pour l'automatisation ne consiste pas à contourner les limitations, mais à concevoir correctement les applications dès le premier jour.

Lorsque les développeurs privilégient la clarté, la cohérence et l'observabilité, tout le monde y gagne : les testeurs écrivent des tests plus rapides et plus fiables ; les utilisateurs bénéficient de logiciels de meilleure qualité et toute l'équipe avance plus vite.

La bonne nouvelle ? La plupart de ces pratiques sont de toute façon de bonnes pratiques d’ingénierie logicielle. Un HTML sémantique, des API prévisibles et une gestion claire des erreurs améliorent l’accessibilité, les performances et l’expérience utilisateur, et pas seulement les tests automatisés.

Préparer : data-testid Utilisez des attributs HTML sémantiques, affichez les états de chargement et documentez vos composants. Vos testeurs d'automatisation vous en remercieront et votre application n'en sera que meilleure.

Ressources et outils

• Documentation Selenium : https://www.selenium.dev/documentation/
• Documentation du dramaturge : https://playwright.dev/docs/intro
• Documentation Appium : http://appium.io/docs/en/about-appium/intro/
• Bibliothèque de tests (Meilleures pratiques de test) : https://testing-library.com/docs/
• Spécification OpenAPI : https://swagger.io/specification/
• Guide des bonnes pratiques de rédaction ARIA : https://www.w3.org/WAI/ARIA/apg/
• Règles d’accessibilité du Web (WCAG) : https://www.w3.org/WAI/WCAG21/quickref/
• Storybook (Documentation des composants) : https://storybook.js.org/
• Modèle Page Object : https://www.selenium.dev/documentation/test_practices/encouraged/page_object_models/