It started with my Unit Test Mock and State Live Together. My friend asked me to explain a bit more about my statement
Unit Test is an art.
It was such an interesting question when he asked: Why do you have this statement?
He made a good point. I promised to give him my thoughts on it.
Things have no meaning unless you label them.
“What UT is” does not matter much. What you think it is matters.
Unit Test (UT) is Code
First and foremost, UT is code. We write a piece of code to test our production code. When comes to code, we have to
- Consider best practices
- Consider maintainability
- Decide what tools to use
- … Thousands of other things
As a developer, I say: Code is an Art.
Point of Views
When working in an organization, when talking about Unit Test, each level has a different view. I will give some of my observations. Please notice that I do not claim anything here. I give my observations.
Non – Technical Manager
He assumes UT is a piece of cake, that we should write UT when there is time.
Problem: There is always NO time.
Half – Technical Manager
Maybe he knows some about UT. He knows the important of UT. He also knows the difficulty of writing UT. Regardless of those he still wants to push for code coverage, and think UT is kind of easy.
I have not seen many developers have the right mindset about UT. And depending on the technical skill, their UT code quality is less than or equal the production code.
I have not seen many developers study UT seriously. To them, it is a nice-to-have thing.
Because of that mindset, their UT code is a maintenance nightmare. Think about when you have to change your production code; when you have to add new code.
Some developers think UT is a joke, a waste of time.
Here is a funny part. Sometimes I heard a story that in a company the manager expects QA to write UT. Oh God!
Many parties just forgot (or pretended to) the fact that UT is code.
When people come to an Art gallery, looking at the same picture. Will they say the same thing? I do not think so.
People look at things depending on their point of views in life. The same event two people might have different opinions. Sometimes, in order to improve something, we simply need to change our view.
Who should change their view? Developers, in my opinion. Developers get the best advantages out of UT.
Here are a few things I suggest you, developers, to begin with
- Do a serious research about UT: What is it? What is it for? What are the best resources to learn it? …
- Start today build the habit of writing UT. The key word is TODAY.
- After a week, review all UT you wrote. You can ask an experienced developer to give you advice.
And you should not
- Study “How to” books at the beginning. “How to” are good only when you know what and why.
- Start TOMORROW.
What you think about UT will determine how good you are as a developer. When reading this post, some might think of TDD. But NO. I am not talking about TDD. I highly recommend you start small.
By no mean, I am a UT expert. I am just trying to make things better every day.
Want to learn more about UT? This The Art of Unit Testing by Roy Osherove is a good resource.