Before we get into the topic, let’s define some vocabularies. I know people will disagree with how I use the term, however, I want to define it so you know what I mean when I use these words.
Unit test - Isolated tests that test a single class. Dependencies are mocked.
Integration test - Tests that test through API. It could reach several classes and/or databases.
A few years ago, my testing structure follows the testing pyramid. By default, I wrote unit test first. I wrote a test for every single functional class. (I usually didn't write test for model/bean because they were simple getter and setter. They usually didn't have a lot of functionality.) I mocked dependencies, regardless if the dependencies were written by me or not. On top of the unit test, I wrote a few integration tests to ensure everything worked well together.
Lately, I noticed that I am leaning toward writing integration tests by default. I find that I am more confident that the code work because I don't have a lot of mocks. I also write less tests because one single test scenario could touch several classes. It is also easier to refactor because the test uses the API, therefore I can change the internal structure as much as I like. There is a downside to this. Integration often takes longer to run. It is harder to pinpoint a bug. Sometimes the setup makes it hard to understand what the test is doing. When I run into these situations, I add unit tests.
Even though I prefer integration heavy test, when I have a resident apprentice, I will make my apprentice follows the testing pyramid and write more unit tests. I believe unit tests train your mind to build cleaner code because it exposes design flaws. When you are writing a unit test and it takes 50 lines to set up the test, there is problem. My philosophy is if it’s hard to unit test, there is probably a code smell. As the apprentice develops a sense for writing clean code, I believe the apprentice will develop his/her own style of testing.
My advice on testing is to write the kind of test that let you sleep at night, literally. When you don’t write test or when you write bad test, things break and you worry when you deploy. Or your code might break at midnight and you have to stay up and fix it. Therefore write tests that makes you feel confident that you won’t have nightmare or midnight emergency.
The reason why robot can’t do our job yet is because we change our style depend on the situation. You can’t go with one extreme or another. Not writing test is bad. However, if it will takes you half a day to write a test so you can change one simple line of code, is it worth it? Can you sleep with changing that code without a test? If you are choosing one practice over another, make sure you understand why. Develop a style that let you have a good night sleep.
Here are a few pros and cons to both style:
Unit testing
Pro
- Run quickly
- Quick bug detection
- Easy to adhere to the single responsibility
Con
- Coupled to the code, thus hard to refactor
- May need a lot of set up for mocks
- May mock the wrong return
Integration test
Pro
- Test code is decoupled from production code, thus allowing you to refactor to your heart content.
- Confidence everything works well together
- Understand how to use the code
Con
- Slow
- Could be a lot of data to set up
- Harder to find bugs
Disclaimer: The content written on here is based purely on my experiences and what I’ve seen so far. It is my opinion at this time. My opinion will change.
