I think this article discusses Unit Testing vs other test types, rather than the use of Mocks specifically.
You make an excellent point that unit tests are not the best type of test in every situation. However, they are a foundation of automated testing. When describing automated testing, many often refer to the testing pyramid. Here, we have layers of test types. In decreasing quantity, we have:
Unit tests
Integration tests
End-to-end tests
Manual testing
The idea being that a project has a large number of unit tests (for classes that are easier to test). Next, we have integration tests where (as you describe) multiple components are tested together. Next are end-to-end tests (e.g. it's difficult to set up an API controller in a test). Finally, we admit there are some things that are very difficult to test automatically (e.g. some languages don't allow mocking of mouse input events), and have a few manual tests for that.
We should be having more unit tests than integration tests as per the test pyramid. Yet often times I see that tests scew towards the unit testing + mocking. Hence this article is a reminder that we also can write other types of tests to better balance the pyramid.
Yes - good point about the distribution of test types.
I suspect that the prevalence TDD has something to do with that. I'm not saying TDD is either good, or bad - I'm just saying that it encourages writing unit tests and then filling in the implementation.
With so many jobs on the market that want TDD as a requirement, my guess is that many people learn to do TDD with unit tests and don't think much about the other possibilities.
I think this article discusses Unit Testing vs other test types, rather than the use of Mocks specifically.
You make an excellent point that unit tests are not the best type of test in every situation. However, they are a foundation of automated testing. When describing automated testing, many often refer to the testing pyramid. Here, we have layers of test types. In decreasing quantity, we have:
The idea being that a project has a large number of unit tests (for classes that are easier to test). Next, we have integration tests where (as you describe) multiple components are tested together. Next are end-to-end tests (e.g. it's difficult to set up an API controller in a test). Finally, we admit there are some things that are very difficult to test automatically (e.g. some languages don't allow mocking of mouse input events), and have a few manual tests for that.
Great point about the test pyramid, Anthony.
We should be having more unit tests than integration tests as per the test pyramid. Yet often times I see that tests scew towards the unit testing + mocking. Hence this article is a reminder that we also can write other types of tests to better balance the pyramid.
Yes - good point about the distribution of test types.
I suspect that the prevalence TDD has something to do with that. I'm not saying TDD is either good, or bad - I'm just saying that it encourages writing unit tests and then filling in the implementation.
With so many jobs on the market that want TDD as a requirement, my guess is that many people learn to do TDD with unit tests and don't think much about the other possibilities.
I agree, TDD is having an effect on this. Although I've done TDD in the past where I wrote couple integration tests which was convinient.
It's definitely worth testing a chain of components when it's the easiest way.