(#bqxlviq) @prologic@twtxt.net Yup, looks good, I also agree with her.

Just a few weeks back I had basically the same idea with inventing a more generic mock implementation for our storage layer at work. Previously, we had tons of new test storage types each implementing another hardcoded behavior based on the exact input. For a start that works well and is incredibly easy, but over time it quickly becomes unmaintainable and also reading the tests is extremely hard. Why is that weird value used as an argument over here? Quite some time later one realizes: Oh, right, it will then trigger that and that.

So my approach basically boils down to the exact same thing Jessica does. To be able to set a mock function in the mocked object that will then do whatever is needed. Setting up more involved tests is now concise and readable. It’s still not perfect, but a large improvement even so. My implementation goes a bit further than Jessica’s and falls back to the real functionality, if not overridden explicitly. This has the advantage to just throw together a bunch of tests without mocking everything, since there are often a lot of steps needed to build the actual scenario.

In Kraftwerk v2 I extended the mock storage to be able to be initialized even more easily with this automatic init(). At work where this mock.Storage type inherits (and not just contains a) memory.Storage forces us to also explicitly create a memory storage for each and every mock.Storage{Storage: memory.NewStorage(…), …}. One day, if I have some time, I’ll refactor the day-job code and apply this simplification, too. Ideally, Go would allow me to write some constructor thingy where I could set up and propagate initial data to the backing memory implementation. Then there’s no chance of forgetting a call to the s.init() in a new function. But that’s the best I’ve come up with so far. I just want to make it as easy as possible to write tests.

So that was very cool for me to see her writing it down as well. It seems my idea the other day was not completely silly. :-) Haven’t seen it anywhere else up until now.

This test subject fits perfectly. Just before quitting time two work mates and I discussed about tests. And one rule we made up now is to prefer table tests, when possible. This helps writing and maintaining better tests. I remember back in the Java days when there were different parameterized test frameworks, as they called it. They worked similarly, but in contrast to Go’s flexibility of the builtin table tests, it doesn’t really compare. Arguably, it’s still heaps of code in Go, but creating parameterized tests in Java was always much more hassle in my opinion. Oh, I need this special runner now, which is the correct one? What was the annotation called again? Oh hang on, now these other tests won’t work anymore with this new test runner, I have to move stuff to new test classes. That’s why I only rarely used them. With Go, it’s a real first-class citizen and not an afterthought and that positively shows. (Not sure if parameterized tests improved after Java 8.)

One thing that the article doesn’t mention, or I already forgot after writing this wall of text. ;-) Thinking about edge cases. That’s super important and often they’re missed in my experience. Here TDD might be a good approach to the problem. Come up with possible cornor cases up front, write some tests and then implement the logic. At least for bug fixes this is a great way. There are limitations of course, if you don’t know in advance how your going to design the API, TDD won’t work in practice. We just had exactly this sitation this week at work. Even with only one fairly simple new function in the end. We threw away four (!) designs and did it quite differently for the final result. If we had strictly followed TDD here, we would have rewritten all our tests a couple of times. And that would have been super annoying and thus demotivating (well, we had to completely rework them once). Granted, that doesn’t happen thiiiis often, but it still occurs every now and then.

One last final thing: I very much enjoy looking at code coverage reports and see a lot of green there. This motivates me writing more tests and thinking of ways I could test that last little thing here as well. And if that turns out to be impossible with reasonable effort, you know that you probably need to refactor things.