Compression TDD et JPEG

Question

Dans le notorious Stack Overflow #38 podcastJoel Spolsky a parlé de la difficulté qu'il y aurait à faire TDD pour quelque chose comme la compression JPEG. Bob Martin wanted to cover comment faire TDD pour une instance comme celle du podcast # 41, mais je ne pense pas qu'ils y soient jamais parvenus. Ainsi:

Comment pourrait-on utiliser TDD pour développer et tester la compression JPEG?

Answer 1

La question de Joel était quelque chose comme ceci. Supposons que vous vouliez définir un bit quelque part qui provoquait l'affichage d'une image basse résolution plutôt qu'une image haute résolution. Comment utiliseriez-vous TDD pour que cela fonctionne? Souhaitez-vous écrire un test qui gratte l'écran pour montrer que l'image était en basse résolution?

Bien sûr que non. Vous savez déjà que la bibliothèque JPEG fonctionne. Vous savez déjà que si vous l'appelez avec les bons arguments, il s'affichera en basse résolution. Ce que vous devez tester, c'est que le bit que vous définissez est traduit dans les appels appropriés à la bibliothèque JPEG. Donc, vous vous moquez de la bibliothèque JPEG avec un module très simple contrôlé par votre test. Ensuite, vous définissez le bit et demandez l'affichage. La bibliothèque JPEG Mocked se souviendra comment il a été appelé, puis le test peut vérifier pour être sûr qu'il a été appelé correctement. OK, alors comment testeriez-vous les composants internes de la bibliothèque JPEG? Je ne connais pas beaucoup le rendu JPEG, mais je présume qu'il s'agit de compression, de décompression et de bitmaps. La compression et la décompression ne sont que des algorithmes. Les algorithmes ont des sorties prévisibles à partir d'entrées données.Donc, vous configurez une série d'entrées très simples et assurez-vous que vous obtenez les sorties prévisibles. Vous configurez les entrées de sorte que les internes des algorithmes JPEG soient couverts. La même logique est valable pour les bitmaps. Vous n'êtes pas obligé de les afficher à l'écran. De petites bitmaps simples peuvent être restituées dans des mémoires tampons que les tests peuvent examiner. Par simple, je veux dire simple. 3X3, 5X5, 8X8. Simple. Encore une fois, vous structurez vos données d'entrée pour couvrir la majeure partie du code.

Rien de tout cela n'est de la science des fusées. Aucun si c'est parfait. Mais une série de 50 tests qui démontrent que 90% de votre logique est correcte peut faire une énorme différence lorsque vous voulez faire des changements. Pouvez-vous éliminer complètement les tests manuels? Bien sûr que non. Mais vous pouvez l'atténuer de manière significative. Vous pouvez réduire les tests manuels à quelques tests très stratégiques plutôt qu'à des milliers de plans de test pénibles.

Answer 2

Si vous pensez que TDD signifie que les tests viennent avant tout code ou tout design, c'est en grande partie impossible. Pour les algorithmes complexes, vous avez besoin de résultats. Et dans le cas de la compression, les résultats sont difficiles à produire à la main. Pas impossible, mais difficile.

En outre, la compression nécessite un algorithme très performant. Le simple fait de passer un test n'est pas assez bon. Beaucoup d'algorithmes de basse performance peuvent passer le test de "correction" de base.

Pour aller au-delà de la correction, vous avez besoin de preuves que votre algorithme est optimal. Cela ne peut être développé qu'en dehors de la vue du monde de test. Vous avez besoin d'une analyse de complexité en utilisant O (quelque chose), ce qui n'est pas le résultat d'un test; il ne peut pas non plus être défini comme les résultats d'un test.

Si, d'un autre côté, vous pensez que "testabilité" vient avant la plupart du code, alors c'est facile.

• Concevez votre algorithme. Ecrivez une preuve que c'est optimal.

• Ecrivez du code qui expose des parties critiques de votre algorithme en tant que modules testables.

• Dans certains cas, écrivez du code pour produire des résultats de test pour l'algorithme global. Cela peut être sous-optimal, le code de force brute qui produit la bonne réponse à travers des algorithmes vraiment évidents, mais lents.

• Assembler un unittest pour montrer que votre implémentation produit les résultats de test attendus.

• Assembler un papier technique pour montrer qu'il est également optimal.

Ce n'est pas le test d'abord. Mais c'est piloté par les tests.

Answer 3

développement piloté par les tests ne sont pas la programmation seulement, il y a beaucoup d'autres choses que vous pouvez faire en utilisant le test d'abord, les exemples sont TDD d'acceptation, etc.

Pensez d'abord comment vous voulez qu'il se comporter, c'est la chose. Pour un algorithme, un exemple pourrait être quelque chose comme:

• « Il doit effectuer 5 appels en 10 secondes »
• « Il faut réduire à 10% la taille de l'image »
• Autres.

je crois qu'il est seulement un mode de vie de penser clairement ce que vous voulez accomplir: D