Executing all tests of the online registrations I’m building for the scouts takes now 70 seconds. Initializing a new SQLite database in RAM and creating all the tables for each test case sums up and takes its time. During development cycles I more often resort to the -run flag for go test to specify only one area of tests to be executed. Much more fun this way to quickly go back to writing code.

At least the service layer line coverage is a whopping 99.5%, branch coverage is 93.3% (the latter could still be bumped slightly). However, only 17.6% lines of the web layer are covered (I definitely should increase this by a lot). This still good test base, if I say so myself, came in extremely handy a lot of times when refactoring stuff. Esp. the service layer changed, web not so much. It slows development down quite a lot, that’s for sure. I reckon it’s easily five to ten times more effort to come up with useful tests than writing productive code, probably even more. I’m bad at guessing. But the confidence of not breaking stuff is sooo much more valuable. The tests certainly paid off in the past, zero doubt about that.

It takes a lot of discipline to first write all the tests in the service layer before doing the web stuff and finally see it in action and play around. It’s funny that I always have to force myself to do so, but in the end, I’m always happy to have done it exactly like that. It once again worked out very smoothely that way. But something inside me wants to fast forward. I wonder if that irrational part eventually fades away.

Having a code coverage report does make a night a day difference. It actually turns writing tests into a fun game for me. The older I get, the more I do enjoy writing tests. Rest assured, producing productive code is still cooler. :-)

I’m also sooo happy about vim-go. I can’t believe how much that sped up and boosted my development process.

Whoops, 57 minutes later, this message turned out much more elaborated that I initially envisioned. Oh well. ;-)