Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Unit tests are never perfect at capturing functionality, particularly in certain parts of an application (such as the GUI), so everyone needs some measure black box testing. Does TDD have anything to say regarding black box testing? If it does not say much, could it be true that while writing unit tests is the developers job, functional black box tests fall into a different domain like that of a business analyst or a dedicated tester?

share|improve this question

3 Answers 3

up vote 4 down vote accepted

TDD has evolved to include black box testing, BDD quite specifically uses it as a device (see ATDD).

However, I don't think this answer tells you in whose domain black box testing lies. Personally, I think it lies with everyone. The BA knows what the business wants and Developers and Testers understand edge cases that a BA should never need to understand, often both with completely different perspectives.

And this is why the Gherkin-based test runners have become popular, because they allow BAs, Devs and Testers to write the test cases in the same language as each other (though developers have to put some code behind the text).

share|improve this answer

Does TDD have anything to say regarding black box testing?

Not really.

You must write the tests first. Therefore, there is no "white box" because the code does not yet exist.

The distinction between black box and white box means essentially nothing in the TDD context.

...could it be true that while writing unit tests is the developers job, functional black box tests fall into a different domain like that of a business analyst or a dedicated tester?

Yes. Of course.

TDD does not mean "rigidly follow some brain-dead path."

If you want to do additional testing of the GUI, that would be a well-accepted idea.

share|improve this answer

IMHO TDD is primarily a whitebox technique, and, I think it is more an implementation technique than a testing technique. It is applied by the developer who writes the code in very small iterations "write test, write code, refactor", so by someone who knows exactly the already implemented parts, and the missing parts of the "subject under test".

Whenever the developer who applies TDD creates a test for a function, he has full knowledge about the already existing implementation, the next missing feature, the next missing edge case, or the still uncovered code paths. That will undoubtly have a big influence which tests he creates and which not.

In fact, there is also a black box element in TDD: whenever you create a new public function to be tested, you have to think about the function signature or the API from the view point of a user of that function or API first. And whenever you add a new test for a functionality your "subject under test" does not support yet, you can do this without having decided about how to implement the functionality in detail. But IMHO that black box part is very different from a real "black box test", where an external tester who may not even be a developer does not have any knowledge about the implementation of a program.

See also: Black box or white box testing - which do you do first?

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.