I was designing something for work a couple of months back. I got a little fancy and added a domain-specific language to the first draft, thinking that it could be useful for handling some special case requirements from the business that we haven’t considered for. I pulled it out in a later revision, thinking to myself “nah, you’re not going to need that anytime soon.”

Well, some changes came through from the business today, and now I wish I kept in that DSL. It hasn’t even been a week. 😛

P.S. I tend to add DLSs into every single project I build so don’t take this post as justification to add a scripting language to your next project just because “it could be useful”. 😉

How can one gain confidence that what they’re testing works if one is using mocks?

I’m grappling with this now as I go through making changes in one of the services I’m working on. So much of the logic requires rework, which means the tests will need to change. And yes, the tests use mocks, meaning that the changes are significant.

But do they have to be? We’re effectively mocking things that can easily run as part of the test. Things like a DynamoDB store — which can run within a Docker container — or even services from other packages. Sure they’re not part of the “unit”, so using them in a unit test won’t make it a “unit test” anymore. But I’d argue that using “real” implementation of dependent systems would produce more confidence in the changes I’m making. I’m able to change the logic without changing much of the test itself. Surely this is worth the “unit test” purity price.

And even if the outcome is meant to change, that intention is made clear by simply changing that in the test, without touching any of the setup code. Nice and readable in the MR: the function was expected to do this, now it does that.

That said, I would concede that there’re legitimate cases for mocking. Namely, if it takes a significant amount of time to setup the dependencies, or you can setup the dependencies within the test itself, mocking is probably the best option. A slow test or, even worse, a test that won’t run if dependent services are unavailable, is worse than a bunch of mocks.

Maybe a good compromise is recognising that excessive mocking in a unit tests is a sign that a module has too many dependencies.

Getting to the point in the photo blogging challenge where I’m saying to myself: “have I posted this photo before?” One of the candidates I had for today, the answer is actually yes. Fortunately I do have an alternative.

Still waiting for the dream to be able to write code on an iPad. There are some good native apps out there for checking out Git repos and editing files with syntax highlighting, but I never use them because there’s nothing in the OS that integrates them all. You’re left with switching between them to do something in your workflow, which is disorientating as each one will take up the whole screen and throw away your context. I suppose there might be Shortcuts — I haven’t explored what it’s capable of — but what I really want is a shell.

The closest that worked for me is a Code Server web-app running in a chromeless browser. It works for me mainly because there is a shell. If the editor doesn’t support a feature, I can use a command to do what I need. I don’t have to switch between apps either: I can see what I’m doing and the files I’m doing it to. I can also build and run them code I’m writing. Fancy that!

Day 15: red

Red mailboxes means the post will go faster. 😉 #mbsept

Day 14: statue #mbsept

Enjoying coffee and breakfast after a really early start and several weeks of hard work, with the satisfaction that the work is now done. Good feeling. 😌

Finished reading: What to Do When It’s Your Turn by Seth Godin 📚