Mar
6
2012
ALM / Architecture

3 bonnes raisons d’utiliser différents frameworks de tests – Tips #1 Bis

Author An article by Patrice    Comments 4 Comments

Suite au relai de mon post sur le très bon test runner proposé par Visual Studio 11 et son support de différents frameworks de tests par Richard Clark, celui-ci se posait la question de l’intérêt de supporter différents frameworks de tests au sein (par exemple) d’une même solution.

image

Je vous propose donc aujourd’hui 3 bonnes raisons d’utiliser différents frameworks de tests :

  • La possibilité de réutiliser, sans migrer, des tests existants tout en switchant (pour tout ou partie) les nouveaux tests sur un nouveau framework. Vous appréciez l’intégration de MS Test mais ne supportez pas le non respect du pattern AAA pour les tests liés à la gestion d’exception ? Continuez d’utiliser MS Test, et utilisez un autre framework comme xUnit qui vous permettra d’avoir des tests de meilleure qualité.
  • Le support de frameworks de tests ciblants différents langages. Exemple : Je développe un site web ASP.net et je souhaite créer et exécuter des tests unitaires et d’intégration pour mon code VB ou C# mais également pour du code javascript. Je peux donc utiliser à présent MS Test, xUnit, nUnit ou autres pour le code managé, mais également Chutzpah pour les tests du code JS.
  • Le support de frameworks de tests proposant différents types de tests. On utilise en effet généralement un seul et même framework pour développer tests unitaires et tests d”intégration, mais il existe d’autres types de framework permettant d’écrire des tests se rapprochant au plus près de la définition des spécifications (comme MSpec), ou proposant une syntaxe naturelle pour les assertions. Il est donc possible de les utiliser de manière complémentaire avec les frameworks plus “traditionnels” avec Shoudly par exemple.
Tags: ,

Related Posts

About the Author: Patrice Lamarche

Leader Technique et ScrumMaster au sein de l'éditeur de logiciels Log'in Space. Je partage ici mes expériences dans le monde du développement avec les technologies Microsoft. Mon intêret et mon objectif principal est d'arriver à apporter plus de maturité à l'équipe de développement dont je fais parti, en mettant en mettant en place des process, des pratiques et outils destinés à améliorer le déroulement des projets. Microsoft MVP Application Lifecycle Management (ALM)

  • http://twitter.com/tjaskula Thomas Jaskula

    Je trouve que le fait que VS11 supporte d’autres frameworks de test que le mlheureux MSTest c’est un bon point.
    Avoir plusieurs tests unitaires dans la même solution ? J’en ai jamais vu et moi même je ne ressent pas l’intêret.
    J’utilise plusieurs frameworks de tests s’il ne s’agit pas de la même typologie de tests (unitaires, d’intégration, UI) mais c’est une autre histoire

  • Anonymous

    Je suis d’accord avec Thomas sur le fait que normalement on ne devrait pas en arriver à avoir besoin d’utiliser plusieurs frameworks de tests au sein d’une même solution, cela rajoute d’une manière générale de la dette technique inutilement.
    D’une manière générale il vaut mieux en prendre un seul choisi au mieux des critères les plus importants pour le projet/l’équipe et adapter le reste.
    Maintenant concernant VS11, le point le plus important est qu’il supporte d’autres frameworks pas forcément qu’il en supporte plusieurs en meme temps ;-)

    Maintenant si je devais aller dans ton sens Patrice pour trouver des bonnes raisons d’en utiliser plusieurs, je dirais que :
    - une raison historique, on est en train de faire évoluer un projet legacy avec du code et tests historiques dans un framework X et on souhaite commencer à porter le nouveau code dans un framework Y qui correspond mieux aux besoins du projet
    - avoir des tests dans un projet de la solution avec un framwork X parce que le framwork convient bien et utiliser sur un autre projet de la solution un framwork qui a une dépendance/limitation particulière sur un framwork de tests (comme un framework de bdd par ex).

  • http://patricelamarche.net Patrice Lamarche

    Cela peut arriver sur des projets qui durent plusieurs années. Il est inutile de rester sur le même framework s’il y a mieux ailleurs.

    De plus la friction est de mon point de vue très faible. Il suffit de comprendre les différences conceptuelles des frameworks, la mise en place technique se fait de manière très très simple. le gap à franchir est vraiment très faible.

    De plus ton commentaire indique donc que tu ne testes que ton code managé, si tu es amené à testé d’autres langages (je ne connais pas le type de projets sur lequel tu travailles), il pourra être fort utile d’en utiliser plusieurs…

  • http://patricelamarche.net Patrice Lamarche

    Je parle bien évidemment d’un contexte de gros projet, où le choix d’un framework de test n’est pas forcément définitif.

    Dans tous les cas, oui il est mieux de prendre du recul en début de projet, mais il faut pour autant en avoir les moyens (niveau technique de l’équipe, maitrise des différents frameworks, etc.).

    Cf ma réponse au commentaire de Thomas.

    Concernant le scope, oui cela peut être utile de séparer en plusieurs projets, ce n’est qu’une question de point de vue.