Tests de service #58
Merged
Tests de service #58
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
prytoegrian
force-pushed
the
pry/behaviorTest
branch
from
ab5c6f3
to
50cab1f
Compare
prytoegrian
force-pushed
the
pry/behaviorTest
branch
from
1538f59
to
d825bba
Compare
|
... Et testé. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
La pyramide des tests est un outil décrit par Martin Fowler dans un article, et est assez répandue dans le génie logiciel. Cette dernière précise que les tests logiciels se découpent (en gros) en 3 grandes classes :
Ces tests doivent être compris et faits dans un ordre précis afin que les variations ne soient pas plus grandes que nécessaires : si un test end to end crash suite à un changement de signature de fonction, c'est qu'il manque un test plus précis. Ce n'est pas son rôle de s'apercevoir de ça.
Bref.
Ça faisait longtemps que ça me turlupinait, je m'étais souvent retrouvé à découvrir des défauts alors qu'il y avait des TU sur les composants. Ces défauts arrivaient, car les objets ne fonctionnaient plus ensembles, j'ai donc décidé de chercher un outil complet de tests de plus haut niveau. Codeception est celui-là. Conçu pour réaliser la totalité des types de tests, il m'a aidé à réaliser les Tests Fonctionnels qui m'intéressaient.
Techniquement, ces tests se branchent sur le routeur de l'appli et passent à travers la totalité des couches, le tout sans serveur, ni web, ni bdd.
Comme tout bon test, j'ai créé des tests doubles, l'un pour la configuration (cf.
ConfigurationFileChecker.php), l'autre pour la BDD en utilisant sqlite pour avoir des données fixtures accessibles très rapidement (merci PDO, cfDBConnector.php).J'ai fait en sorte que ces tests, puisqu'ils sont plus couvrants, ne se lancent que lorsque l'on merge sur
master.La poursuite de cet objectif est de faire un pas de plus vers l'intégration continue, où chaque jalon est capable d'affirmer GO / NO GO sur la bonne santé du logiciel. Mon souhait est qu'en faisant ça, on soit beaucoup plus décomplexés dans nos développements (les tests nous montrant nos erreurs). Nous coderons ainsi plus vite, sans erreur, et nous pourrons supprimer des étapes superflues, comme la
beta, améliorant ainsi le feedback utilisateur, et par suite notre pertinence fonctionnelle.