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?
Does TDD Use Black Box Testing to Supplement Unit Tests?
testingunit testing
Related Solutions
However, it implies that large parts of the applications code are not covered by tests. Why? Because if you have units (and you need a lot of units to get your Unit Tests right) you need code that wires the units together. This code, IMHO, will get complicated enough that it deserves to be tested on a more granular level that integration tests while it probably falls into "Dirty Hybris":
Your assumption is faulty because you are neglecting a layer of testing - acceptance testing.
Your unit tests cover individual units - the classes and methods that compose them. This enables you to test methods and classes in isolation to ensure that they are behaving as expected. Above this lies your integration tests, which tests the collaboration between classes and ensures that larger modules (packages and even inter-package collaboration) work as expected. Finally, your acceptance tests are used to verify and validate your entire system, as assembled, against the user requirements.
Assuming that you have the appropriate unit and integration tests that correspond to requirements and well-defined acceptance criteria and acceptance test plans, then everything in your system is tested. Other aspects of testing - smoke tests, regression tests, and so forth, are simply an appropriate subsampling of the unit, integration, and acceptance tests.
TDD is a robust way of designing software components (“units”) interactively so that their behaviour is specified through unit tests
That particular quote is also missing something. As I was taught, TDD isn't just about unit tests, but developing all tests first. That includes not only unit tests, but the necessary acceptance and integration tests as well.
Unit tests are white-box tests and usually written by the developers of the thing being tested. The first means that you need first-class interaction with the APIs and objects and values of the language the actual product is written in, which rules out almost all combinations of languages. In fact, I think the CLR is the only agglomeration of languages that each can call into each other perfectly. And as you say, most CLR languages are so similar that none of the advantages you suggest apply.
That leaves pretty much only the combination of F# and C#/VB.NET. I can imagine several reasons this hasn't taken off:
- F# doesn't have that big of a community. Conversely, most C# developers don't know enough F# to even consider this.
- The people who do know F# are either busy writing both unit tests and actual code in F#, or in a team where they can't use F# at all because nobody else knows it (well). As mentioned before, unit tests are usually not written by a separate team, so people who write C# unit tests for F# code probably still have to know F#. Plus the whole white-box thing: If you don't know a thing about functional programming, even the data structures and APIs exposed by (idiomatic) F# will be unnatural for you once you delve deeper than very simple libraries of the form "put in a URL here, receive
IEnumerable<UrlParameter>. - There's no benefit (or people don't believe the benefit), but quite possibly some very real friction from switching languages constantly.
Best Answer
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).