TDD
January 20, 2016
I didn't give up on this blog. I promise. I have just been busy with work. I finally started building my new blog website and I should be switching over in the next month. I decided that instead of just hacking together a blog, something that would be quick and I would already be done with, I would try to use some new development and architecture methodologies. For the architecture I am trying to make sure everything has dependencies on the application and that the application depends on nothing, code wise. I will explain that in more detail during a later blog. For this new blog I am also going to try my hardest to do it TDD.I have found myself in the same camp as a lot of people that I have read on the internet. I have barely tried and just said "I don't like it. It's not for me." However, I feel that isn't really fair. If I have never embraced it enough to give it a good faith effort, I can't really say it isn't for me. So with that I have decided that I will force myself to develop each component using TDD.
To Start off, it is admittedly going a bit slower than I would hope. Part of that is TDD and part of that is that I am trying to change my coding habits in general so that I build better architectures (Once again, more on that in a later blog). Surprisingly though, I am enjoying it more than I thought I would.
I don't agree that it leads to a better design in general. I still think that falls on the developer. However, there are a few things that I do think it helps with.
- I find myself debugging a lot less than I did in the past.
- My unit tests end up being less brittle than when I test after coding.
- I get quick satisfaction that I am making progress.
The 3rd one is really important to me when I am working on non-UI parts of the code. I really like the immediate feedback when working on the UI and you don't get that as much in the lower tiers of the program. Doing TDD brings the immediate feedback to the lower levels of code.
I have also noticed a few common complaints about TDD that I thought I would attempt to address. These are complaints that I really gave it a true chance. The first is that it will slow you down. This is true in the beginning. It takes a little bit longer to get started. However, I have noticed that my debugging time has decreased astronomically. I now understand how it speeds you up in the long run. It is mainly just because you rarely have to bring up the debugger.
The second common complaint is "TDD doesn't work well when you have a lot of third party API's and data sources that you pull from." I think this one can be resolved with good architecture. If you invert the dependency so that the third party data sources (i.e. database) depend on your application and not the other way around it changes things dramatically. If your application controls the contract of how things will work then you can still test that your application works with the given contract. Maybe you don't TDD the layer that implements the contract and pulls from the third party source, but you can still TDD the application. If you keep all the application logic in the application itself then you don't have to worry about the third party datasources being a burden to your TDD. This will also keep your unit tests from being brittle because now they don't have to change at all if the third party changes their API.
The third complaint that I read a lot goes something like this. "I don't know where I am going in the code so I can't really write a test before I start." I have this same problem. First of all, TDD does allow you to do spikes to hack together something that works. What you need to do after that though is pull it all out of your code. Now that you know how it works you can start again with a new failing test. Keep the spike for reference if you get lost. This seemed counter intuitive to me when I first started as well. It sounds like this would almost double your development time. It doesn't because the second time you write something you can do it faster. Also, you were going to refactor the hacked code anyways so just think of the rewrite as a refactor.
The reason that I address these complaints is that I had them too. I am not going to be evangelical about it though. To me coding methodology is a personal choice and you aren't going to get someone to convert just by calling them names. I will however continue to use it and see if I can improve my development skills.