DEV Community

Discussion on: Code coverage testing, when enough is enough

Collapse
 
peppesilletti_4 profile image
Giuseppe Silletti

I may be wrong, but it looks like you're saying that unit tests can be only white box tests, but they can definitely be black box (see pure functions).

Anyways, I'd also be wary of using white box tests at all because that couples the tests to the implementation logic, so it makes maintenance a bit more annoying. Tests become just another client of your classes/functions.

Collapse
 
jmitchell38488 profile image
Justin Mitchell

In this article I'm not suggesting either, simply code coverage can be extracted from white and black box testing. The method in which tests are created and executed after entirely the purview of the developer(s) that write them.

Whitebox testing is typically the scope of unit tests, whereas blackbox testing is more the scope of automated integration and user behaviour testing. Tools can be used across either, it's a preference thing for how you want to test. These days, the lines are pretty much blurred except when using older, more specific and semantic languages like .net, Java, etc.

For example, you can use Cypress, typically a blackbox testing tool, to write whitebox tests. You can do whitebox and blackbox testing with Jasmine, Jest and pretty much any other FE JavaScript testing tool, if you so desired.

Agree on both points about coupling. There's strategies to mitigate against it, such as using the white box tests as an extension of behavioural tests, but when code coverage is a measurement of confidence, there really isn't an alternative for a lot of developers.