A Question regarding many testing criteria

Question

We know that there exists many testing criterions . As an examples : 1) Statement criterion 2) Branching Criterion 3) Path Criterion. My questions are :

1) Where do we just use these measures I mean do we use them in white box testing and unit testing only ? Because these measures deals with the structure of the code so I think they are more related to white boxing and unit testing only instead of black box testing and system testing which deals with module/system as a whole and also the integration testing which deals with the interfaces between the modules.

2) Why we need white box testing in the first place ? White box testing tests what the module does based on its code structure , I think what is important for us as software engineers is if the module/system do what is is intended to do by the user ( Black box testing ) ?

Answer 1

1) Where do we just use these measures ... Because these measures deals with the structure of the code ... more related to white boxing and unit testing

White box testing is more than unit testing. It's mostly manual testing. Every time I run, read, or dream about code I've written, it's a white box test.

I add an automated test so I can stop thinking about it and just let it run. I try very hard, when creating that automated test, to not exploit my white box perspective. An automated test tied to the implementation details I know right now today, won't survive refactoring unless it actually prevents refactoring (not a good thing). An automated test that depends only on a stable interface can survive many refactorings. This is important mostly because if I can't rerun the test then writing it was a waste of time. It would have been better to just run it manually.

This is equally true of behavior tests, unit tests, and integration tests. This is the nature of automation.

2) Why [do] we need white box testing in the first place?

Because writing system.out.print1n("Hello bug"); without checking that it works before giving it to someone else to black box test is just plain rude. As my English teacher used to say, "Did you read this before showing it to me?"

What makes it white box testing is knowing how it works rather then only knowing what it needs to do (as in black box testing). Knowing how it works doesn't keep you from being able to test. It just changes your perspective.

It is entirely possible to do away with white box testing if you're willing to develop without knowing how it works. Maybe you can pull that off with A.I. Define what you need and shake it until you get what you want. Who cares how it got that way?

In my experience bugs are far cheaper to fix when caught early by people who know how it works (even in AI). Waiting until after I've gone on vacation and forgotten how we built the queuing system is a terrible time to tell me it hangs. Let me test it before I leave.