Skip to main content

Test Driven Development Doesn't Mean Test First

By
I’m a fraud and here’s why.

I am a huge advocate of Test Driven Development (TDD). I’ve even written an introduction to TDD. In his book Test Driven Development by Example [TDDbyExample] Kent Beck defines TDD as a process where you must write tests for code before writing the code itself. Therefore if you’re doing TDD you have to write the tests first, right? Wrong!

I really feel like unburdening, so here’s another admissions. I’m addicted to the green bar and high code coverage percentages. For those that are unfamiliar with the green bar, it’s a feature of the JUnit (and other testing framework) GUI. If all your tests pass you get a green bar. If any of your tests fail, you get a red bar. I’m addicted to the green bar, I can’t sleep without it. There are tools that allow you to measure how much of your code is exercised by your tests as a percentage. Usually anything over 80% coverage is considered good. I always strive for 100%, but usually achieve high 90s. I can’t sleep without high code coverage either. It’s very important that you bear these two vices in mind as you read on as they give me a discipline that not all software developers have. This isn’t because I’m some super software developer. It’s an affliction, believe me. If you don’t have this discipline, write your tests first.

There are many advantages to TDD. The two that stand out for me are loosely coupled code and code that’s easy to test (obviously). Actually by making your code easy to test it becomes loosely coupled and easy to change by default and that’s the point I’m making. If you want to get the green bar and have high code coverage then you need to make your code testable. Writing the tests first forces you to make your code testable, but it’s not the only way. If your tests are automated and measuring code coverage is automated or better still your continuous integration system runs your tests and measures the code coverage you’re forced to make your code testable. The key, when writing your code is to think about how you’re going to test it and write the tests soon after. This is a skill that has to be learnt and the best way to learn it is to start test first. Once you have it nailed though, you too will become addicted to the green bar and high code coverage. Of course you still have to write the tests, before you’ve written too much code, and refactor to remove duplicate code. It’s important to keep running the tests and to make sure they pass every time you make a change to the code. Many developers are lazy and don't bother. My affliction means that if I'm lazy, I don't sleep. It's a curse.





Comments

Post a Comment

Popular posts from this blog

Write Your Own Load Balancer: A worked Example

By
I was out walking with a techie friend of mine I’d not seen for a while and he asked me if I’d written anything recently. I hadn’t, other than an article on data sharing a few months before and I realised I was missing it. Well, not the writing itself, but the end result. In the last few weeks, another friend of mine, John Cricket , has been setting weekly code challenges via linkedin and his new website, https://codingchallenges.fyi/ . They were all quite interesting, but one in particular on writing load balancers appealed, so I thought I’d kill two birds with one stone and write up a worked example. You’ll find my worked example below. The challenge itself is italics and voice is that of John Crickets. The Coding Challenge https://codingchallenges.fyi/challenges/challenge-load-balancer/ Write Your Own Load Balancer This challenge is to build your own application layer load balancer. A load balancer sits in front of a group of servers and routes client requests across all of the serv
Post a Comment
Read more

Catalina-Ant for Tomcat 7

By
I recently upgraded from Tomcat 6 to Tomcat 7 and all of my Ant deployment scripts stopped working. I eventually worked out why and made the necessary changes, but there doesn’t seem to be a complete description of how to use Catalina-Ant for Tomcat 7 on the web so I thought I'd write one. To start with, make sure Tomcat manager is configured for use by Catalina-Ant. Make sure that manager-script is included in the roles for one of the users in TOMCAT_HOME/conf/tomcat-users.xml . For example: <tomcat-users> <user name="admin" password="s3cr£t" roles="manager-gui, manager-script "/> </tomcat-users> Catalina-Ant for Tomcat 6 was encapsulated within a single JAR file. Catalina-Ant for Tomcat 7 requires four JAR files. One from TOMCAT_HOME/bin : tomcat-juli.jar and three from TOMCAT_HOME/lib: catalina-ant.jar tomcat-coyote.jar tomcat-util.jar There are at least three ways of making the JARs available to Ant: Copy the JARs into th
22 comments
Read more

Bloodstock 2009

By
This year was one of the best Bloodstock s ever, which surprised me as the line up didn't look too strong. I haven't come away with a list of bands I want to buy all the albums of, but I did enjoy a lot of the performances. Insomnium[6] sound a lot like Swallow the Sun and Paradise Lost. They put on a very good show. I find a lot of old thrash bands quite boring, but Sodom[5] were quite good. They could have done with a second guitarist and the bass broke in the first song and it seemed to take ages to get it fixed. Saxon[8] gave us some some classic traditional heavy metal. Solid, as expected. The best bit was, following the guitarist standing on a monitor, Biff Bifford ripped off the sign saying "DO NOT STAND" and showed it to the audience. Once their sound was sorted, Arch Enemy[10] stole the show. They turned out not only to be the best band of the day, but of the festival, but then that's what you'd expect from Arch Enemy. Carcass[4] were very disappoin
1 comment
Read more