Concevoir un framework de zéro : les couches

L'idée, en une ligne

Découpez le framework en couches, pour qu'un changement à un endroit ne se répercute jamais partout ailleurs. C'est ce que « architecture » veut vraiment dire ici.

Les six couches

• Config — réglages d'environnement : URLs de base, timeouts, identifiants. Tirez-les de variables d'env, ne les codez jamais en dur.
• Core — la plomberie : la factory de driver ou de client, une classe de test de base, les attentes et helpers partagés.
• Pages (ou clients d'API) — enveloppent l'app pour que les tests parlent en termes clairs comme login_page.sign_in(user), pas des sélecteurs bruts.
• Données — factories et fixtures qui construisent des entrées valides : utilisateurs, commandes, payloads.
• Tests — minces. Arranger, agir, vérifier. Ils devraient se lire comme une spec.
• Reporting — capture les résultats, captures d'écran et logs comme artefacts sauvegardés.

Pourquoi le découper ainsi

La règle derrière le découpage est la fréquence à laquelle chaque chose change. Les sélecteurs changent tout le temps, donc ils vivent dans Pages. Les environnements changent à chaque exécution, donc ils vivent dans Config. Les tests devraient à peine changer. Quand vous isolez les parties qui bougent vite, une modification reste une modification.

# A layered project keeps change contained
# framework/
# +- config/       # settings, env vars, base URLs
# |    settings.py
# +- core/         # driver factory, base classes, waits
# |    base_page.py
# +- pages/        # one class per screen (UI) or resource (API)
# |    login_page.py
# +- data/         # factories + builders for test inputs
# |    user_factory.py
# +- tests/        # thin: arrange, act, assert
# |    test_login.py
# +- conftest.py   # fixtures wire the layers together
#
# A selector change touches only pages/
# A new environment touches only config/  -- never tests/

Lisez-le de haut en bas : chaque dossier possède une tâche. Si un changement vous force à éditer plusieurs dossiers à la fois, c'est un signe que les couches fuient l'une dans l'autre.

Avancé — ce que les examinateurs écoutent

Quand quelqu'un demande « comment ton framework est-il structuré », la liste des couches n'est que la moitié de la réponse. L'autre moitié est le pourquoi — reliez chaque couche à son rythme de changement. Ce raisonnement est ce qui vous distingue comme architecte plutôt que comme rédacteur de tests.

Basé sur la doc pytest (bonnes pratiques d'intégration) et les conseils Page Object Model de la doc Selenium