Unit-testing – black box unit testing

tddtestingunit testing

I recently had my final exam for a software engineering course for my masters program and one of the questions on the exam was the following:

Unit Testing is considered:
a. White-box Testing
b. Black-box Testing
c. Either

In my 7 years of software development experience, unit testing has always taken a white box approach. The tester has always had full knowledge of the implementation of the unit while writing the tests. Black box testing always came later in the forms of integration, system, and acceptance testing.

However, the correct answer to the exam (according to the professor) is that unit testing can be either white or black box testing.

I have done some research, and it seems many cases "black box unit testing" is used to describe a test-first approach where the unit tests are written before the code is. However in my opinion this is still white box testing. While the implementation does not yet exist, whoever is writing the test generally has a pretty good idea about how the source code is going to be implemented.

Can someone please explain to me how black box unit testing works (if it truly is a thing) and how it differs from white box unit testing?

Best Answer

Your professor is right: unit testing can be either black-box or white-box. The difference is less about what the tester knows, but more about how you generate test cases.

With black box testing, you only look at the interface and (if it exists) the specification for a component. When a function has a signature int foo(int a, int b), then I can immediately generate a few test cases just by testing interesting integers: zero, one, minus one, multi-digit numbers, INT_MAX, INT_MAX - 1 and so on. Black box tests are great because they are independent from the implementation. But they might also miss important cases.

With a white-box test, I look at the implementation, i.e. the source code and generate test cases from that. For example, I might want to achieve 100% path coverage for a function. I then choose input values so that all paths are taken. White-box tests are great because they can exhaustively exercise a piece of code, with far more confidence than a black-box tests. But they might be only testing implementation details, not actually important behaviour. In some cases, they are clearly a waste of time.

Since a white-box test is derived from the implementation, it can only be written afterwards. A black-box test is derived from the design/interface/specification, and can therefore be written before or after the implementation. TDD is neither clearly black-box or white-box. Since all behaviour is first expressed by a test and then the minimal code for that behaviour is implemented, TDD results in similar test cases to a white box test. But when we look at the information flow, TDD tests are not derived from the source code, but from external requirements. Therefore, TDD is more black-box-like.

Related Topic