Le code « Legacy » peut être défini comme l’ensemble du code qui n’est pas testé unitairement. Ce code est difficilement réutilisable car non couvert par des tests automatisés, couvrant la non-régression. Comment en venir à bout? Et d’ailleurs, doit on en venir à bout?
Dans l’équipe nous avons l’habitude de considérer que le code « Legacy » est l’ensemble du code qui n’est pas testé unitairement (je crois l’avoir déjà lu dans un bouquin, n’hésitez pas à commenter si vous savez). Ce code est difficilement réutilisable car non couvert par des tests automatisés de non-régression.
Le sujet des tests unitaires est tellement vaste qu’il me faudra beaucoup plus d’un article pour en faire le tour… Voici quelques points clés qui seront abordés plus en détail au cours du temps: Lire la suite
Aujourd’hui je vais vous parler d’un problème rencontré par un de mes collègues: Il souhaitait utiliser le mock d’un objet mais il ne parvenait pas à trouver les propriétés exposées par la classe parente. Lire la suite
Le mocking d’objets:
Aujourd’hui, je présente à l’équipe R&D le mocking (en fait j’ai présenté le stubbing et le mocking, mais la suite de l’article décrit plutôt ce qu’est le stubbing, j’expliquerai la différence entre le stubbing et le mocking dans un autre article) d’objets afin de mettre à niveau tous les développeurs sur ce qu’il est possible de faire avec les tests unitaires. Lire la suite
