Bonne remarque :) Je ne suis pas du tout expert sur le sujet, donc ma réponse est à prendre avec des pincettes. Pour moi c'est une question de nuance. Certaines classes n'auront aucun TU directement associés, car elles seront complétement couvertes par d'autres tests. D'autres seront complètement couvertes par des tests spécifiques si leur fonctionnalité est complexe.
Mais je manque d'arguments et de ressources pour détailler cette nuance :/

@xtrembaker, lorsque j'ai une méthode un peu tricky comme tu dis, c'est surrement un élément important/complexe de ton business. Je te recommande alors de sortir cet élément dans une classe distincte dédié à l'implémentation de cette algo. ca te permet donc de dégager une partie "complexe" de ta classe mère, de sans doute mieux respecter le principe de single responsability
Ca te permettra de faire peut etre apparaitre mieux dans ton code un concept métier (si méthode compliqué c'est bien que c'est un point sensible métier normalement)
En le mettant dans une classe dédié, tu pourras aussi le remplacer plus simplement (par exemple ca devient facile de remplacer l'appel de cette classe dédié par une interface et ca ouvre la porte à la possibilité de switcher facilement d'implémentation, imagine que tu as une idée pour améliorer l'algo en question ou améliorer sa vitesse, bim ca devient possible facilement par le fait que tu ai extrait l'algo dans une classe dédié)

Globalement, je trouve qu'il est préférable de partir des Use Case en TDD et de faire emerger les ports quand on a besoin d'interagir avec l'extérieur.

Pour approfondir, je pense que tu trouveras des gens intéressés par ces questions sur le slack de Wealcome de Michaël Azerhad.

join.slack.com/...

Merci Marc pour ce lien

I use to work on ZX 80 at university ;-)) Merci pour ce partage ce qui me plait c'est que vous faites la synthèse de l'évolution avec une vision

Vous utilisez un système de queue ?
Si oui lequel ?
Et surtout : pourquoi lui ?

Merci pour ce guide complet. J'ai pas mal utilisé RabbitMQ à l'époque où je bossais dans l'IOT. Nous avions fait ce choix car la plupart de nos objets connectés ainsi que nos partenaires utilisaient le protocole MQTT. Dans mon précédent job, nous utilisions Kafka mais je n'ai pas eu l'occasion de jouer avec. J'ai également eu l'occasion de bosser (très brièvement) sur un projet qui utilisait ZeroMQ pour faire de la communication interprocessus.