Comments for SalientBlue

Comment on …it’s not a Unit Test by Ted M. Young (@jitterted)

Ted M. Young (@jitterted) — Thu, 20 Oct 2011 22:54:45 +0000

(You need to start numbering these for easy referral, e.g., this test INAUT#10.)

I’d generalize “If the mock setup code dwarfs the actual test code… it’s not a Unit Test.” with simply “If the setup code is bigger than the test code…INAUT”. AKA, Test Setup Sermon.

Comment on …it’s not a Unit Test by Pablosan

Pablosan — Thu, 20 Oct 2011 12:16:41 +0000

Thanks for the comment! Looking at your post now…

Yes, what we are testing and how long the tests take to run are valuable foci. I compiled this list from coaching many teams on good testing practices, not because I want teams to focus on them, but because I find it helpful to use ONE or TWO of these statements to jar someone’s thinking. After many years of coaching, I thought it would be fun to take a light-hearted approach to thinking about Unit Tests.

Comment on …it’s not a Unit Test by Pablosan

Pablosan — Thu, 20 Oct 2011 12:12:02 +0000

I completely agree; especially on the “no assertions it’s not a test” point! I’m perfectly find with violating any of these as a short-term approach to getting ANY/SOME test coverage so that refactoring can be done safely. Sadly I find most often that the refactoring is put off indefinitely.

So “do what ya gotta do”, but recognize it as technical debt and don’t let that debt continue to grow!

Comment on …it’s not a Unit Test by Pablosan

Pablosan — Thu, 20 Oct 2011 12:06:12 +0000

Hi Jeff!

Thanks for the comment! When working with legacy code there is no doubt that the state of the code under test makes limiting mocking difficult. I consider that to be a smell: something seems wrong. In the case of extensive mocking being required to get a test up and running, my experience has always been that there are major design problems in the code: encapsulation has been violated, a class is trying to do too much (violates Single Responsibility Principle), etc.

Sometimes, though, I find that the test is unnecessarily complex. I’ve seen this in codebases where a mocking framework has been used for a while and the framework ends up getting abused. So, while a mocking framework can be a very good thing, it can also be an enabler for bad test design.

So while I agree that sometimes extensive setup is required, I would challenge you to consider that as technical debt and look for refactoring opportunities to improve the design of both the code under test and the tests themselves.

Comment on …it’s not a Unit Test by Pablosan

Pablosan — Thu, 20 Oct 2011 11:55:00 +0000

Excellent! I think I will eventually update my post with some of the viewer additions. They’re great!

Comment on …it’s not a Unit Test by Pablosan

Pablosan — Thu, 20 Oct 2011 11:54:01 +0000

Very true. These are mostly negative descriptions of integration tests. However, I find it useful when working with new teams to give them an idea of what a Unit Test is NOT… and I just finally decided to take a light-hearted approach to compiling a list.

Comment on …it’s not a Unit Test by Pablosan

Pablosan — Thu, 20 Oct 2011 11:52:25 +0000

Brilliant!

Comment on …it’s not a Unit Test by Thomas Koch

Thomas Koch — Thu, 20 Oct 2011 07:21:14 +0000

If the test run touches half of all classes of your application … it’s not a unit test
If either all tests pass or nearly half of them fail if you change one line of code – INAUT

Comment on …it’s not a Unit Test by mika

mika — Thu, 20 Oct 2011 00:38:25 +0000

Here is a superset :

If it’s an Integration Test …. it’s not a Unit Test.

Comment on …it’s not a Unit Test by Fabio Pereira

Fabio Pereira — Thu, 20 Oct 2011 00:09:59 +0000

I find it a lot more relevant and useful to discuss and understand WHAT functionality the tests are testing and how long they take to run other than what we really call them (unit, integration, poporn, bacon). I have been finding a lot of tests that ARE called “unit tests”, if we use your definition criteria above, but they don’t test anything really. I call those tests Tautological and the practice of writing those tests TTDD – TautologicalTDD.

When we educate people that unit tests have to follow all those rules the tests end up becoming tautological due to the fact that everyone tries to isolate every single dependency around a single class.

I’d appreciate some feedback and your thoughts on this as well… Cheers

http://fabiopereira.me/blog/2010/05/27/ttdd-tautological-test-driven-development-anti-pattern/