John: Hey, John Sonmez from simpleprogrammer.com.
This week, I want to talk about, yes, a technical topic.
Iím going to be talking about test driven development.
Iíve got a few controversial views on test driven development, but Iíll explain why
I hold those views.
Hopefully, Iíll convince you at least to some degree that what Iím saying makes some
sense.
I used to be a really big proponent of test driven development.
I used to really push for it really hard way back when hardly anyone was doing unit test.
Definitely, not very many people were doing test driven development.
I would often go into an organization or join a team, and Iíd really push for test driven
development and for unit testing.
This was a good thing.
I ended up improving a lot of the quality of code by pushing for test driven development
and pushing for unit testing in general, but I was a little bit too strict about this.
I had code coverage requirements of around 95% asking that 95% of the production code
be covered by tests.
Obviously, my views have changed on test driven development or I wouldnít be telling you
this.
They haven't changed a huge degree.
Theyíve changed to be more pragmatic.
At least thatís how I think of it.
Let me explain, first of all, why I think test driven development is good, especially
if youíre not doing any kind of unit testing at all, Iíd encourage you to do some kind
of test driven development.
Thatís because the biggest benefit for me for doing test driven development that I found
is it helps you become better at writing good code.
The reason why this is true is because when you write the test first, it forces you to
use the APIs of your code.
It forces you to use that production code so that influences you to make the structure
of that code better for being used and to be more understandable.
When we just write a bunch of code first where you donít think about how itís going to
be used, we are guessing at how people are going to use it or how easy this is going
to be to use.
When you write unit test first and then you write the code to make those unit test pass,
youíre basically starting out by defining the API which is really valuable for writing
quality clear code thatís easy to understand.
Thatís really the big benefit for me.
Of course, thereís regression as well.
You can run those unit tests but I tend to think that regression is not so important
anymore as far as unit testing goes.
Now, donít get me wrong.
You still have automated test at a higher level, but as far as unit testing goes those
regression tests really donít prove much.
I found that in most complicated software systems when you unit test fail, we have to
go and try and debug this and figure out why this unit test fail and most of the time itís
a false alarm.
I would say that there were very few times that a unit test has failed where I said,
ìOh, this caught a bug.î More often than not, Iíve gone and said, ìWell, is this
test actually correct?î or, ìOh, yeah, yeah.
That was expected,î or, ìThis mock failed.î Thatís the bad side of it.
Let me tell you what I think now.
I think now that test driven is like training wheels for writing good code.
It should be used in certain cases but not all the time.
A lot of times we end up just blanket and force test driven development.
What we end up having is a code that has tons of mocks or dependencies passed in.
We might use inversion of control or dependency inversion containers to try and pass all kinds
of dependencies into our code, and then weíre just going to mock it up in unit tests when
weíre doing test driven development.
This is a bad way to go because those tests become harder to write than the actual code
and the test code that we write ends up being error prone and we could have bugs in the
test codes.
Who is going to test the test code?
Are we going to write tests to test the test code?
No, weíre not going to do that.
I think it makes a lot of sense to be pragmatic about it.
If youíre just starting out writing code, you should definitely be doing test driven
development for all your code because you need to learn how to write a good code.
When I started doing test driven development it really taught me how to write good code,
how to write good APIs and really improve the quality of my code.
If youíve been writing code for a while, if youíve been doing test driven development,
you will probably find this point where you start to feel like these tests arenít adding
value.
When you feel like tests arenít adding value, this is my personal belief, stop writing those
tests.
You want to be able to test code with your test driven development or when youíre writing
a unit test that makes sense where itís going to give you some value from doing that.
If you feel like itís not creating value, stop doing it because chances are itís not
creating value.
You can refactor your code and structure your code in such a way that it makes it easier
to write unit tests.
Iíve written up on my blog about Ö there are only 2 roles of code.
If you do a search for 2 roles of code, you will find my post.
Basically, I say that there are algorithms and then thereís a code that ties everything
together.
If you can separate your code out better into those 2 types and donít have it mixed together
in classes, then you can write unit tests or you can do test driven development on the
algorithm part and not have a lot of dependencies, not have to use a lot of mocks.
Those tests are going to be highly valuable and itís just going to be really beneficial
to you.
If you have everything mixed together and youíre finding that youíre having to write
a lot of mocks and you find that your test code is really complicated, then you might
really want to question the value of doing test driven development in that case.
Overall, with my view, I think test driven development is good.
Itís really, really good for beginners.
If youíre starting out you need to start practicing this in order to become better
at development.
As you get more experience, you have to use your common sense.
You have to be pragmatic about it.
If you feel like the tests arenít adding value or theyíre just wasting time, then
that might be true.
Well, I hope this video didnít get you too ticked off.
I definitely have a different view on test driven development than I did earlier in my
career.
Like I said, this comes from my experience.
If you disagree with me, let me know.
Send me a comment down below or send me an e-mail.
Donít forget to subscribe to this channel and I hope you have a good week, and I will
talk to you again next time.
See you later.