Tests unitaires

Cet article décrit des cas de tests unitaires, des plus communs à certains plus complexes, sur une application web en Vue.js. Vous pouvez lire l'article Vue.js en TDD au préalable, qui se concentre d'avantage sur la méthodologie de test (Test Driven Development). Cet article-ci décrit un panel de cas de tests plus large, en utilisant l'utilitaire officiel vue-test-utils et le framework de test Jest.  1/ Jest Jest est un framework de test développé et utilisé par Facebook pour tester unitairement du code JavaScript. Son principal objectif…

Vous êtes déjà un expert TDD, votre application a une couverture de tests de plus 80%. Mais vous avez le sentiment que tout n'est pas testé, qu'il reste d'obscurs cas que vous n'arrivez pas exprimer. Pourquoi ne pas demander à un programme de vous aider à tester ? Vous pouvez déjà passer par le mutation testing. Cette méthode donne une première approche, mais il en existe une autre : les tests par propriétés. Cette méthode se résume à exprimer des propriétés et de laisser un programme la…

En présentant les tests fonctionnels automatisés chez un client la semaine dernière, plusieurs questions ont été soulevées. La principale était celle-ci: - Pourquoi écrire ces tests FitNesse/GreenPepper alors que j'ai déjà des tests unitaires JUnit qui couvrent la même fonctionnalité ? La question est justifiée. Voici quelques éléments de réponse, tirés de nos échanges sur les mailing-lists OCTO...

Si vous avez déjà créé une application Ruby on Rails, vous avez déjà dû voir un étrange répertoire : tests. N'ayez pas peur, tout a été fait pour faciliter la mise en place de tests de bout en bout avec Rails. Je vais donc vous donner les méthodes que j'apprécie et que je considère efficaces pour l'écriture de tests en Rails. Que vous soyez novices ou expert, j'espère pouvoir vous en apprendre un peu. Tous les exemples donnés seront pour Rails 3, mais ils sont pratiquement…

Mutation Testing Il n'est plus à prouver l'utilité des tests unitaires. Ils sont essentiels dans la conception d'une application de qualité. Mais, savons-nous quantifier leur pertinence, leur qualité ? Un indicateur de couverture du code par les tests à 100%, ne signifie pas du code 100% testé. Cet indicateur ne détermine que  grossièrement le pourcentage de code exécuté lors du passage des tests unitaires, pas plus. Voici une technique qui vous permettra d’accorder plus de confiance à vos tests. Le processus de cette technique se déroule en deux grandes étapes…

Imaginons un projet mobile avec des délais très restreints et une équipe qui n’est pas familière avec la mise en place de tests unitaires sur iPhone/iPad, ça vous rappelle quelque chose ? Sur ce type de projet les tests unitaires sont souvent quasi inexistants, et les équipes sont axées sur la réalisation plutôt que sur la pérennisation de leurs développements. Pourtant la mise en place d’une couverture minimale de test peut être simple, c’est ce que nous allons voir dans cet article.

Travaillant avec les technos Web, j'ai souvent été confronté à Javascript. Java-iste dans l'âme, j'ai été un peu rebuté par ce langage interprété (non compilé), faiblement typé, basée sur la notion de prototype (donc sans classe !)… bref, trop souple pour être vraiment sérieux ! Si on ajoute à cela qu'il existe un moteur par version de navigateur (actuellement on a Chakra chez IE9, V8 pour Chrome, TraceMonkey chez Firefox3.5, SquirrelFish pour Safari ou encore Carakan pour Opera10…) ce sont les maux  de tête assurés…

Le débat autour du ROI des tests unitaires et du TDD (Test Driven Development) ne date pas d'hier comme cet article du blog Octo de 2008 en témoigne : https://blog.octo.com/le-roi-du-tdd/ Les questions soulevées sont somme-toute naturelles : même convaincu du bien fondé de cette démarche, il est toujours intéressant d'avoir une estimation de combien coûte cet investissement. Idem lorsqu'on souhaite démarrer un projet en TDD, comment intégrer cette donnée dans le chiffrage ? Doit-on prévoir +20%, +100%, rien du tout ? Les chiffres tangibles sont rares,…

Afin de tester nos développements iPhone nous utilisons largement les frameworks Google-Toolbox-for-Mac et OCMock (cf Tests unitaires et tests d’interface sur iPhone : État des lieux) Après la mise à jour du SDK4 et le passage à Xcode 3.2.3 nous avons eu une désagréable surprise : nos frameworks de tests ne compilaient plus et jusqu'à aujourd'hui on trouve très peu d'information sur la façon de régler ce problème. Voici comment nous nous y sommes pris :

Dans un précédent article sur la mise en place d’une Usine de dev iPhone nous avions promis un article sur la pratique des tests unitaires sur iPhone, le voici ! Venant de l’univers JAVA où ce sujet est très présent, nous avons voulu reproduire sur nos projets iPhone les bonnes pratiques de tests automatisés auxquelles nous étions habitués. Néanmoins la situation est bien différente sur une application mobile et sur iPhone en particulier : l'interface graphique est au cœur de l’application, et celle-ci semble particulièrement…