Romain

What are the interesting go developers' accounts to follow on bsky?

BTW I think I will eventually get back to C.

Rust comes next, it looks much complicated but go reduces the gap.

Why go?
Concision
Fast build time
Performance
Straightforward dependency management

I decided to learn Go, as a kind of new year resolution.
I'm fed up with interpreted languages.

This week I learned I can change billing period from hourly to monthly on OVH Public Cloud instances.
I'll provision VM hourly now and switch them to monthly billing once they're installed and validated.
Meanwhile, I can suspend them and save some €
€€

Et vous, amis lecteurs, que pensez vous de l'outside in TDD ?

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.

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 ?

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é.

Vous vous assurez comme ça de bien orchestrer tous les éléments de votre architecture logicielle.

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…

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.

Je m'essaie à outside in TDD en ce moment. Un truc de gens qui boivent du thé et qui conduisent du mauvais côté de la route.

Amis lecteurs, que pensez vous des mocks / simulacres dans vos langages de programmation favoris ?

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.

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.

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 !

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...

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...

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.

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.

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.

Vous passez à côté d'un truc ÉNORME pour vos tests.