4 ms·

The problem with this kind of advise is that projects are all very different - there is no one fit way to test it.

misja111 9y ago
This is the only true statement that can be made about this whole integration-/ unit testing debate but it will never be popular because it doesn't seem to be simple enough. Most people like black and white guidelines. 'Unit testing is good, integration testing is bad', something along those lines. Simple to remember, simple to apply. Unfortunately it doesn't match reality. The truth is, every testing strategy is a tradeoff. Integration tests are great at catching regressions and verifying business requirements, but they can take a lot of time to construct, tend to be slow and don't give you much clues where to find the error when they fail. Unit tests are fast, easy to build and when they are well written they will point you right to the point of your code that is wrong. However, the more specific they are, the more they tend to test your implementation choices instead of real business requirements. But even the above is not always right. When you are building a library, you might be able to create unit tests that test your api and then you have the best of both worlds, your unit tests do actually verify your business requirements. On the other hand, it might be that you are building an application which doesn't depend on a lot of data and which can be orchestrated pretty well in a test set up, and therefore integration tests are actually easy to build; in that case you'd like to focus more on integration tests. Tl;Dr; there is no silver bullet, in the end the only right thing to do is let your test strategy depend on the characteristics of the project.
rb808 9y ago
Absolutely - this is the key. There is a huge difference in the software for a game engine vs a website vs an MIS report vs a trading system vs an autopilot. You can't blanket statement which testing technique is better for all software.

This is the only true statement that can be made about this whole integration-/ unit testing debate but it will never be popular because it doesn't seem to be simple enough. Most people like black and white guidelines. 'Unit testing is good, integration testing is bad', something along those lines. Simple to remember, simple to apply. Unfortunately it doesn't match reality. The truth is, every testing strategy is a tradeoff. Integration tests are great at catching regressions and verifying business requirements, but they can take a lot of time to construct, tend to be slow and don't give you much clues where to find the error when they fail. Unit tests are fast, easy to build and when they are well written they will point you right to the point of your code that is wrong. However, the more specific they are, the more they tend to test your implementation choices instead of real business requirements. But even the above is not always right. When you are building a library, you might be able to create unit tests that test your api and then you have the best of both worlds, your unit tests do actually verify your business requirements. On the other hand, it might be that you are building an application which doesn't depend on a lot of data and which can be orchestrated pretty well in a test set up, and therefore integration tests are actually easy to build; in that case you'd like to focus more on integration tests. Tl;Dr; there is no silver bullet, in the end the only right thing to do is let your test strategy depend on the characteristics of the project.

rb808 9y ago

Absolutely - this is the key. There is a huge difference in the software for a game engine vs a website vs an MIS report vs a trading system vs an autopilot. You can't blanket statement which testing technique is better for all software.