Comments on: My Views On Test Driven Development

By: John Callaway

John Callaway — Fri, 25 Mar 2016 14:37:00 +0000

I’ve just switch jobs from an organization where TDD was “just how it’s done” to one where “our clients don’t want to pay for testing”. Unfortunately we’re eating a lot in support and maintenance, if you can imagine. I’ve already presented a sandbox project with proper separation and testing. Hopefully it will be a quick and easy transition as I introduce TDD at the new gig.

By: jsonmez

jsonmez — Thu, 10 Apr 2014 12:05:00 +0000

In reply to Umais. You are absolutely correct. I agree. :)

By: Umais

Umais — Wed, 09 Apr 2014 20:54:00 +0000

I agree that sometimes unit test adds unnecessary burden and aren’t that useful. However , the code we write should be testable and we should always keep separation of concerns , repository pattern and other useful patterns in mind when building database driven apps. We do not have to go crazy with IoC and patterns but at least it will be easier for us to implement good testable code if we go in the right path from the beginning. Making the code modular and thinking about reusable and API’s is definitely the way to go regardless of whether it is a small project or a big project. The extra effort will really payoff in the long run. This is my opinion please feel free to disagree.

By: jsonmez

jsonmez — Thu, 03 Apr 2014 01:58:00 +0000

In reply to Albin Sunnanbo. Yes, exactly. :)

By: sunilrav

sunilrav — Wed, 02 Apr 2014 22:35:00 +0000

Tough to take sides. Sometimes, a code change in a particular area ends up affecting other areas which we totally do not foresee and come to light only when the tests start failing. I still find code coverage of 95% of the non framework related code a worthy goal, just so we can catch the unforeseen bugs in other areas of the system before we go to production.

By: Albin Sunnanbo

Albin Sunnanbo — Tue, 01 Apr 2014 17:09:00 +0000

Finally someone that dares to say that unit testing is not always the silver bullet!

The phrasing about separating the logic and the glue put words on something that has been on my mind for a while.

I have found that unit testing sometimes forces you to over complicate your architecture. IoC containers and interfaces all over the place when you only have one implementation¹ that could be really straight forward.
In my experience most of the bugs appear at the integration level in your application and you can’t catch that with unit tests.

When you are creating a simple html view of a database record unit testing only gets in the way, but if you are writing algorithmic or library code unit testing² and TDD improves both developer focus and quality.

¹) With your mocking framework as your second implementation.
²) In short code where the public interface is an API and not a GUI.

By: jsonmez

jsonmez — Mon, 31 Mar 2014 03:58:00 +0000

In reply to Dominik Liebler. Yeah, that is common now. Many teams seem to have lost sight of why we started unit testing to being with. They are just doing it "because."

By: jsonmez

jsonmez — Mon, 31 Mar 2014 03:57:00 +0000

In reply to llewellyn falco.

I’m with ya on that one. Went through that same progression–except I went blackbox automated tests instead of approval tests (but pretty similiar.)

And I agree with you about the ‘hard to test’ as a smell.

I’ve actually found that I can divide my code into algorithms and wiring code, here is something I wrote up about it: https://simpleprogrammer.com/2012/10/21/there-are-only-two-roles-of-code/

That makes it easier to test and I test the algorithms.

By: llewellyn falco

llewellyn falco — Mon, 31 Mar 2014 02:51:00 +0000

you said that learning TDD was important and taught you be a better programmer. I found that was the case myself.
Then I started to struggle.
Then I learned BDD and it made me a better programmer. Then I started to struggle.
Then I learned ApprovalTesting. It made me a better programmer. But still I struggle.
Struggle with legacy code, struggle with javascript frameworks (meteor in particular), struggle with database refactoring.
Eventually I learned how to test them, but still more issues come up.

All of this has lead me the think of ‘hard to test’ as a smell. I agree that the answer isn’t to just write long tests with little return value.
But I think the answer is to learn how to make those situations easy to test.

Also, If you are deciding to not write tests and you have zero bugs in production and are willing to stay with the maintenance phase of a project, then that is one thing. If you think tests are not worth it, bugs are just ‘part of programming’ and maintenance is hard and tedious then that is an other thing.

By: Dominik Liebler

Dominik Liebler — Sun, 30 Mar 2014 09:16:00 +0000

I came to the same conclusions just recently. I am in a project where complexity is just minimal, yet the client wants unit tests. I would go for (automated) integration tests, but I don’t see why I should do unit tests. In the end it all feels I am writing tests just to have a “green build” in Jenkins, without fixing some real bugs, fixing test code instead. This just takes up too many time and is not valuable at all.