Avantages d’un prestataire informatique offshore pour les PME et stratup
décembre 27, 2024La digitalisation des processus occupe une place essentielle dans les PME. Lors du choix de leur système d’information (SI), beaucoup...
Le terme QA pour assurance qualité désigne l’ensemble des procédures pour garantir la conformité d’une application avec les exigences client. Il permet de détecter un maximum de défauts (bugs) avant la mise en production de toute application. Pour réaliser cela il existe plusieurs méthodes parmi lesquelles le BDD et le TDD. Cet article a pour but d’illustrer leur différences.
Le BDD, ou Behavior Driven Development, consiste à piloter les développements par des tests qui valident le comportement attendu d’une application. Dans l’approche BDD, on place les cas d’utilisation au centre des éléments à tester. La réussite des tests va, donc, piloter l’avancement du projet. Ainsi, on s’assure de la conformité des développements avec le résultat attendu. Ces tests sont parfois appelés tests d’intégration. Ils prennent souvent la forme de scripts automatisés qui testent l’interface d’une application.
Le TDD, ou Test Driven Development, repose sur l’idée d’écrire les tests unitaires avant la réalisation d’une fonctionnalité. Ces tests sont principalement du code pour tester du code. Ils sont écrits par le développeur, souvent sans concertation avec les responsables métier (product owner, UX, etc.), mais plutôt en réponse à des spécifications fonctionnelles et des bonnes pratiques. Contrairement au BDD, les tests unitaires concernent toutes les composantes du code.
Le TDD concerne donc tous les éléments, y compris les composantes internes du code. En revanche, le BDD verra le système comme une boîte noire. Si des tests unitaires sont écrits pour tester uniquement les points d’entrée du système, alors ce ne sont pas de vrais tests unitaires ; il s’agit plutôt de BDD déguisé. Pour visualiser la différence, supposons une application modélisée par le schéma ci-dessous :
Cette application est composée de trois modules : les points d’entrée, symbolisés par « Web endpoints », un module A, un module B et une base de données. Le module B utilise des données issues du module A, qui lui-même utilise et transforme les données issues des points d’entrée de l’application (en général une API ou une interface utilisateur). Si nous appliquons le TDD, nous aurons des tests unitaires modélisés de la manière suivante :
Les tests sont indépendants les uns des autres, de sorte que les modules A et B seront testés séparément. Dans le cas du BDD, les modules A et B étant internes au système, ils ne pourront donc pas être testés directement. Seuls les points d’entrée seront testés. Ce sera donc au travers des tests du module « Web endpoints » que les modules A et B seront validés.
Il n’est peut-être pas nécessaire que les modules A et B soient testés unitairement, au final. Une autre différence réside dans le fait que dès qu’une modification de code est effectuée, il y a de fortes chances que des tests unitaires doivent être mis à jour. En revanche, pour le BDD, ce n’est qu’en cas de changement d’interface, d’API ou d’expérience utilisateur que les tests devront être adaptés.
En conclusion, le TDD permet de couvrir bien plus de cas de tests que le BDD, mais peut s’avérer plus chronophage. Il faut également noter que le TDD est écrit dans le langage de l’application, tandis que le BDD peut être écrit dans un langage indépendant de celui de l’application. Cela implique moins de maintenance pour le BDD en cas de migration technologique du code.
Lorsqu’un projet est au stade initial, tout dépendra de sa complexité, de son domaine et de son budget. On ne teste pas une application de gestion interne de la même manière qu’un site web avec un tunnel d’achat, par exemple. Dans de nombreux cas, nous préconisons de commencer par du BDD. Une fois une fonctionnalité terminée, il est ensuite possible d’automatiser ces tests pour les intégrer dans le CI/CD. Ils deviennent ainsi des tests de non-régression.
Les tests de non-régression permettent de vérifier que les modifications du code n’impactent pas les fonctionnalités déjà existantes. En procédant ainsi, on économise du temps sur l’écriture de ces tests. Avec les méthodes agiles, il est possible d’ajouter ces tests à la fin du développement de chaque nouvelle fonctionnalité.
Même si beaucoup diront qu’il faut faire les deux, dans les faits, le BDD utilisé pour les tests de non-régression constitue un minimum. Il permet de s’assurer que le système fonctionne dans les conditions réelles. Le TDD sera obligatoire pour certains développements, comme un module réutilisable, une API externe ou un système embarqué. Dans tous les cas, l’implication de toutes les parties prenantes d’un projet lors des phases de test est un gage de réussite.
Nous réalisons le BDD en utilisant Robot Framework, intégré au CI/CD.
La digitalisation des processus occupe une place essentielle dans les PME. Lors du choix de leur système d’information (SI), beaucoup...
Après avoir développé de nombreux sites WordPress, il est évident que certains plugins sont incontournables. Dans cet article, nous listons...
Développeur Rust offshore De façon à étoffer notre offre et proposer de nouvelles solutions techniques pour nos clients, nous...