Romain
romaintouze.bsky.social
Romain
@romaintouze.bsky.social
What are the interesting go developers' accounts to follow on bsky?
January 18, 2025 at 3:26 PM
BTW I think I will eventually get back to C.
January 18, 2025 at 3:26 PM
Rust comes next, it looks much complicated but go reduces the gap.
January 18, 2025 at 3:26 PM
Why go?
Concision
Fast build time
Performance
Straightforward dependency management
January 18, 2025 at 3:26 PM
Et vous, amis lecteurs, que pensez vous de l'outside in TDD ?
December 3, 2024 at 9:40 AM
Mon approche c'est plutôt de faire plein de tests unitaires niveau use cases et entités et de brancher quand c'est prêt.
C'est moins pénible mais aussi moins exhaustif.
December 3, 2024 at 9:40 AM
Ce que j'aime moins c'est que les tests d'acceptation sont longs à écrire et lents à s'exécuter. Faut-il en écrire pour chaque fonctionnalité, ou juste pour les happy paths et couvrir plus de cas avec des tests en isolations ?
December 3, 2024 at 9:40 AM
Ce que j'aime bien c'est qu'une fois que le test d'acceptation e2e passe, c'est que votre développement est terminé.
December 3, 2024 at 9:40 AM
Vous vous assurez comme ça de bien orchestrer tous les éléments de votre architecture logicielle.
December 3, 2024 at 9:40 AM
Vous progressez ensuite couche par couche en utilisant des mocks aux frontières. Par exemple, votre Controller utilise un mock de votre use case. Le use case utilise un mock de repository…
December 3, 2024 at 9:40 AM
L'idée c'est que vous partez d'un test d'acceptation de bout en bout qui reste en échec le temps de terminer votre développement.
December 3, 2024 at 9:40 AM
Amis lecteurs, que pensez vous des mocks / simulacres dans vos langages de programmation favoris ?
November 27, 2024 at 3:46 PM
Pss : je suis développeur freelance. Si vous voulez que j'accompagne vos équipes pour faire du TDD, ce sera avec plaisir. Je ne me mockerai pas de vous, promis.
November 27, 2024 at 3:46 PM
Relativisons : certes en Java la compilation vérifie que votre implémentation cible est conforme à l'interface qui est utilisée par le simulacre. Pourtant si votre implémentation renvoie une runtime exception "NotImplemented", vous avez le même problème.
November 27, 2024 at 3:46 PM
Sans surprise, la limitation en Python est que vous ne disposez pas d'interface pour décrire le contrat auquel doit se conformer votre classe. Vous pouvez avoir des tests qui passent avec une implémentation cible qui n'existe même pas !
November 27, 2024 at 3:46 PM
En Python, l'objet MagicMock est génial car il permet de paramétrer finement les valeurs de retour et les attendus pour chaque méthode à partir d'un objet complètement vide -> docs.python.org/3/library/un...
unittest.mock — mock object library
Source code: Lib/unittest/mock.py unittest.mock is a library for testing in Python. It allows you to replace parts of your system under test with mock objects and make assertions about how they hav...
docs.python.org
November 27, 2024 at 3:46 PM
Pourquoi c'est pas bien par rapport à écrire vos simulacres à la main ? L'abstraction est portée par un dialecte à apprendre pour paramétrer vos implementations. Vous pouvez facilement faire des erreurs qui remettent en question l'utilité de vos tests.
November 27, 2024 at 3:46 PM
Pourquoi c'est bien plutôt que d'écrire des simulacres à la main ? Parce que vous pouvez définir vos comportements et vérifications très rapidement.
November 27, 2024 at 3:46 PM
Après des années à faire la fine bouche pour ne pas utiliser de framework de mocks, j'ai joué avec Mockito en Java la semaine dernière et unittest.mock de Python cette semaine.
November 27, 2024 at 3:46 PM