I'm a Systems Reliability and DevOps engineer for Netdata Inc. When not working, I enjoy studying linguistics and history, playing video games, and cooking all kinds of international cuisine.
One of the side projects I'm working on involves a couple of potential back end modules for a given front end module. I could, in theory, test each back end completely independently of the front end API provided by the main module. However, I'm 'unit' testing the back end modules through the front end module instead. Which back end is in use needs to be completely opaque to consumers of the front end API and not change anything about the API behavior (except possibly timings, but nothing should be depending on that for this API), so the 'unit' really is the combination of front end and back end because that's the whole 'unit' from the perspective of every consumer of this API.
However, that testing does step through every possible code path that could be run by a consumer of this API, because I do need to check all of that. I also do have a test for the front end by itself so that I can be certain it's calling into the back ends properly, which in turn means that if some of the tests fail, I can be certain if it's the front end or the back end without having to test the back ends in isolation.
This is how I think about it too, and I'm convinced this is the most value for least cost of all the testing approaches I've come across. Very well put.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
'Unit' is what you define it as.
One of the side projects I'm working on involves a couple of potential back end modules for a given front end module. I could, in theory, test each back end completely independently of the front end API provided by the main module. However, I'm 'unit' testing the back end modules through the front end module instead. Which back end is in use needs to be completely opaque to consumers of the front end API and not change anything about the API behavior (except possibly timings, but nothing should be depending on that for this API), so the 'unit' really is the combination of front end and back end because that's the whole 'unit' from the perspective of every consumer of this API.
However, that testing does step through every possible code path that could be run by a consumer of this API, because I do need to check all of that. I also do have a test for the front end by itself so that I can be certain it's calling into the back ends properly, which in turn means that if some of the tests fail, I can be certain if it's the front end or the back end without having to test the back ends in isolation.
This is how I think about it too, and I'm convinced this is the most value for least cost of all the testing approaches I've come across. Very well put.