Write tests first

Published on Sunday 28 July 2019 | 2 minute read

Yesterday I wrote about laying strong foundations for this website that I am developing in 100 days of code, and also more generally.

In today's coding I maintained this, and wrote more tests. I've been writing tests for other projects for a while now, but today the penny really dropped in understanding the different application of unit, feature, and browser testing. This was helped in a large part by this answer in a Laracasts discussion, and this Medium post, which effectively illustrates what the Laracasts answer is talking about. With this new understanding, I was more confidently able to write tests for the creating and editing side of these writings.

But that's an aside really. I just wanted those two links for future reference and to note my coding activity for today. What's important is the principle of writing tests first. This is the fundamental principle behind test driven development (TDD). In TDD you write your tests before you add a capability or feature to the code you are developing. The first time you run a TDD test, we want it to fail.

Why though, do we want tests that fail? By writing our tests first, we are forced to think about the precise way that we want an application to behave, and write that in a terse way. Once our tests are written, we then write code for the capability or feature, until the test passes. If we did it the other way round, bias comes in that makes us write tests to pass the functionality. It's like writing the method and hypothesis for a science experiment after you have done it and have the results. Sure, it will work, but our bias will be to fit these to the results - whatever they were - rather than to robustly interrogate our approach. Doing it the TDD way, we end up with a much stronger, better designed product.

I used the simile of science, and in fact in science this is a real problem. The journal Nature reports that in "an attempt to replicate 100 studies resulted in successful replications for just over one-third of them". That's a shockingly low success rate. The result of this a TDD approach - Registered Reports.

With Registered Reports "peer review and the decision to publish precede data collection and analysis. A researcher will submit what is essentially a detailed plan — a protocol — for a research project for publication in a journal. This will include the research question to be asked, along with a description of the study design and methodology, and a detailed analysis plan."

So it's just like TDD - declare your methodology and analysis approach before you do any actual science or code development. Your outcomes and reliability will be much more robust as a result.

My code and writing this article took me an hour and a half today. Tomorrow, I will add in a little feature that shows when a posts has been recently added. I will, of course, write the test for it before I add the feature. The day after that, I think I'll add the ability to show formatted code in these posts.

#100DaysOfCode #Day5

Made by Ed in Somerset. 2019.