re: The tragedy of 100% code coverage VIEW POST

FULL DISCUSSION
 

I haven't done much formal testing myself, and definitely not any unit testing. While trying to understand it a bit more, I came across a really good paper: rbcs-us.com/documents/Why-Most-Uni...

What are your thoughts?

 

Mr. Coplein is above my pay-grade, so I will let Uncle Bob argue with him :)

m.youtube.com/watch?v=KtHQGs3zFAM

Personally, I always say that system level test are the best and only ones that we should write, if they could be run in a few seconds, in isolation by several developers at the same time.

In my personal experience, the systems that I work with are composed of several docens of moving parts, so system level test end up being too slow, brittle and hard to debug.

I wasn't there, but I think that is a big reason why unit test were born, out of pragmatism.

As Stéphane says in the comment, you need a good mix of test, but tests are not a substitute for thinking!

I would recommend Rich Hickey talk "Hammock Driven Development" m.youtube.com/watch?v=f84n5oFoZBc (all talks by Rich Hickey are excellent!) and Uncle Bob blog blog.cleancoder.com

Thanks for the question and the pdf!

 

Personally, I always say that system level test are the best and only ones that we should write, if they could be run in a few seconds, in isolation by several developers at the same time.

100x this!

Oh and don't forget: Collaborate with the business representative (product manager, product owner, business analyst, whatever) on your high-level test cases! You will be surprised how good both of your understanding of that tested feature will become.

code of conduct - report abuse