From: Stefan Schmiedl Date: 2001-12-11T17:20:47+09:00 Subject: [ruby-talk:28184] Re: John Roth dolt ( Re: A challenge to proponents of Unit Testing. ) Universe (2001-12-11 15:22): > Robert C. Martin wrote: > >That's correct. Unit tests are white box tests. They are fragile to > >significant changes of design. > > Why? Why wouldn't unit testing only worry about robustly meeting > behavioral requirements. because that would leave implementation flaws undetected. with white-box unit tests you could ensure that third-party libraries show the same behaviour over releases. since the environment never sees them, > > >Acceptance tests, on the other hand, > >are black box tests that are completely insensative to changes in > >design. You need both kinds of tests. > > Please explain, why unit tests are white box, while acceptance - unit, > or other? - are not. because unit tests are written by the programmer while she implements the user story. acceptance tests are provided by the user, who is interested in the macroscopic behaviour of the program. In the triangle classification example, the user need not know if we use a Set to automatically eliminate duplicates or store the sides in three variables and do everything in some horribly nested if statements. > > You all don't even get one of the big bennies of testing by units. > Being able to plug working units together purely based upon behavioral > design contract. why not? we still have an external interface to our objects, which is used for plugging. > ... polemic snipped ... > > >>This means that some future refactoring may make your tests inadequate, > >>but the coder doing the refactoring would rely on your tests and check > >>in broken code. > > Am I the only one who thinks this happening is awful? why is it awful? by refactoring you are effectively changing the implementation, hence you need to adapt your tests to the situation. > > >One would hope that the programmers who were making the change would > >review the tests. > > All you have for this travesty is "one would hope"? if you like it more, "the XP process requires it". but the xp-way tends to rely on people more than other processes. > > > One would also hope that there was an acceptance > >test or two that would catch the bug. But in the end, you are right, > >there are some design changes that might produce bugs that could pass > >through the tests. I don't consider this a severe problem for most > >projects since the incidence is not likely to be high. > > Really? In which Bizzaro world? This goes against the most basic > ideas and proven practices with regard to both encapsulation and > testing. would you please provide an example of design changes that are proven not to create bugs which may go unnoticed for some time? > > >>> If your unit tests are large and complicated, you have a design problem, not > >>> a testing problem. > > >>Again, this can only be true if your testing is dictated by the design, > >>*rather than by the requirements.* > > Then you *do* have a design problem Because we established up above > that for unit tests, you "white box" test based upon unit > implementation. ??? we have a design problem, when our code refuses to be changed. we don't have one, when implementation tests change, when the implementation changes. > > >>That's not just backwards, it is > >>doubly dangerous in the XP milieu, where frequent changes to the design > >>are encouraged, and the only validation of those changes comes from the > >>pre-existing tests. > > >Again, remember that XP has two kinds of tests. White box unit tests > >and black box acceptance tests. > > How does that obviate the dangers of your unit testing process in this > regard? i still fail to see the dangers of our approach. s. -- Stefan Schmiedl EDV-Beratung, Programmierung, Schulung Loreleystr. 5, 94315 Straubing, Germany Tel. (0 94 21) 74 01 06 Public Key: http://xss.de/stefan.public shhhh ... I can't hear my code!