First of all,
even if i do not agree with the message of your article, it's a well written one and explains clearly how to test WEB APIs as a whole , so thanks you.
Now on the part a disagree with, here is my point of view.
Integration tests are costly, e2e tests are even more.
I would always recommend unit testing first unless it's not possible (design issues that force to do integration tests).
When developping a feature, you can do unit tests within your workflow (TDD). Which allow for early bug fixing and early refactoring.
It's impossible to do the same with integration testing since you need to have developped a huge part of your system before even considering it.
And even then, how can you be confident where is the issue when you have integration errors?
You have no unit tests, the problems you'll face could be in one part of a pretty Big system.. And it may even not be an integration issue... You'll have a hard time debugging and fixing.
Integration tests are there to check integration issues, not check your code has no bugs. Unit tests are here for that.
I do agree with you that Integration testing requires more time setting up than Unit testing. I also do agree that with Integration Tests you will spend more time debugging and locating the exact place in the code that errored out. Yet, the Pros will outweigh the Cons.
Unit testing might give you confidence in one layer, say a Service layer. However when you run the Controller, Service and Repository together - there is no proof that it's all working.
You might re-use a lot of your setup across different Integration tests. Once you spend time setting it up for one test, you will most likely save time setting it up for other tests.
Obviously it might happen that Unit testing is better for a given project than Integration test, but my post was largely targeted to general CRUD web services where you would get the most benefits with Integration testing.
I guess the truth is somewhere in the middle. TDD can be done on integration tests as well. Also, on unit tests you usually have to mock out stuff, but what are you going to mock if you haven't yet decided on the implementation? In the end, the test design choice of a good developer beats a static rule of what tests to write first.
That being said, the best developer experience I ever had was on a project where I had to extend integration tests and then build functionality for it. Some unit test were there as well, but had only been build in the start of the project. Newer parts were not unit tested. When the bigger picture of the project became clear the shift was made from unit test to integration test driven design. I think I'm going to advocate this flow as well if I'm at a new project inception.
First of all,
even if i do not agree with the message of your article, it's a well written one and explains clearly how to test WEB APIs as a whole , so thanks you.
Now on the part a disagree with, here is my point of view.
Integration tests are costly, e2e tests are even more.
I would always recommend unit testing first unless it's not possible (design issues that force to do integration tests).
When developping a feature, you can do unit tests within your workflow (TDD). Which allow for early bug fixing and early refactoring.
It's impossible to do the same with integration testing since you need to have developped a huge part of your system before even considering it.
And even then, how can you be confident where is the issue when you have integration errors?
You have no unit tests, the problems you'll face could be in one part of a pretty Big system.. And it may even not be an integration issue... You'll have a hard time debugging and fixing.
Integration tests are there to check integration issues, not check your code has no bugs. Unit tests are here for that.
Thanks for reading.
Thanks for the comment and for reading my post.
I do agree with you that Integration testing requires more time setting up than Unit testing. I also do agree that with Integration Tests you will spend more time debugging and locating the exact place in the code that errored out. Yet, the Pros will outweigh the Cons.
Unit testing might give you confidence in one layer, say a Service layer. However when you run the Controller, Service and Repository together - there is no proof that it's all working.
You might re-use a lot of your setup across different Integration tests. Once you spend time setting it up for one test, you will most likely save time setting it up for other tests.
Obviously it might happen that Unit testing is better for a given project than Integration test, but my post was largely targeted to general CRUD web services where you would get the most benefits with Integration testing.
Loved reading through your comment!
I guess the truth is somewhere in the middle. TDD can be done on integration tests as well. Also, on unit tests you usually have to mock out stuff, but what are you going to mock if you haven't yet decided on the implementation? In the end, the test design choice of a good developer beats a static rule of what tests to write first.
That being said, the best developer experience I ever had was on a project where I had to extend integration tests and then build functionality for it. Some unit test were there as well, but had only been build in the start of the project. Newer parts were not unit tested. When the bigger picture of the project became clear the shift was made from unit test to integration test driven design. I think I'm going to advocate this flow as well if I'm at a new project inception.
I had similar experience where I would TDD with integration tests. Worked well