I use tests frameworks all the time. Whether I do TDD or try a code sample. It’s the faster way isn’t it ?
I become a “green addict”. I feel unconfortable when I’m not seeing green dots on my test runner - or when I do not see red dots when I change code (which frightens me much more).
Why ?
Because like cats, I like confort.
My confort is determined by the fastness of the feedback I get when modifying code.
I don’t like testing
I don’t like to run manual tests. It is not fun and scenarii can be very complicated to run.
I used to work on a software that displays data using a moving time window. QA team had tests that ran on several days.
So they were unhappy whenever we modify code. They fear any changes, because they ran manual testing. So do the devs. We knew we were exposed to late-found regressions just because of the manual tests durations.
So I do my best with unit tests to avoid running manual tests.
Tests are talking to me..
I’m not crazy. Altough being crazy is a matter of perspective ^^.
Tests defintely talks. You hear them in statements like “crap ! how am I suppose to test this ?" or “I can’t write the test because this dependency is instanciated with a new.." or “two more day and I’ll have this method covered.".
This is tests whispering to you. As you see, they send Cassandra like visions sometime.
But you will also hear “Should_create_someDependency” failed from the IoC dependency tests.
IoC dependency test is a very powerful test. It tests the dependencies graph. So when you forget to register a dependency, it fails.
Just reading the name of the failing test, pinpoint the guilty class(es). You don’t even have to launch your app. The stacktrace is crystal clear because the test instanciates one class.
Be brave
When there is a test suite running, it should be fine. Investing time in automated tests is supposed to be in your team’s culture.
Problem is, when you have the cassandra like visions. I’ve faced those situations so far:
Quality matters, go
That’s the best situation. Improving code quality is definitely in the culture of your team.
You might have to gather around a table to decide how you’re going to refactor.
Tests is not production code
Worst case scenario. I actually heard this for real. It was really heartbreaking.
You’ll have to find allies in your team to change minds. Beware it takes a lot of time and energy.
I suggest you protect yourself by setting a timebox for this kind of quest. When time’s up, let go.
Next time, ask about the clean code practice in the project ;).
No one cares
That’s an interesting position. I would play the TDD card here and maybe BDD too if I have the time. After a while you might hear “it’s weird, the application is more stable”.
When it happens with team leader around, you might end up mentoring your team mates on TDD/BDD.
I also suggest to define a timebox in this situation. It costs a lot to convince people to change.
In the end
Keep in mind that you might come to the “Test is not production code” situation. In the beginning your mate will come to you and say “your test is failing”, and do nothing.
You have to educate them about testing. I once activate unbreakable build in TFS. I did it as a joke. Sometime, code didn’t compile at all ! In the end we kept it for month because we regain control of our code and QA’s trust.
A commando minded developper I worked with for a few months told me he misses the software factory we had. He missed the green patches and the automated deployment ;).
It’s easy to change code, but hard to change people.