On 3/27/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: [SNIP] > > I don't think it's easier to write test cases for internals though a > public API, because you can call the internal methods directly to see if > they do as they promise, where it's not so easy to always have the same > thing happen through an indirect public API. > > Also, wrt things breaking..... yes, tests that ensure that something > works as expected will need to change if the expectation changes. > > That also is exactly what you want, right? To know if you broke a > 'internal contract' in a class?
Hmmm... Lemme support Richard's point. At the first, internals not just specify 'internal functional contracts', but design decisions. Making redesign you will probably have some (design-dependent) unit tests failing, despite functionality is not changed. If so we will have to change the tests, right? If we changing the tests we cannot be sure they still tests the original behavior. IMHO, tests are the formal and executable way to represent requirements (XP approach) so they should reflect the 'requirements level'. In our case that is public API. At the second, what we really need to satisfy is API behavior only. Internal implementation is not significantly important if public part works fine. I fond of XP and test-driven development and don't feel that we need to test something which is not part of requirements :-). If something is not accessible from the usage scenarios of public API level, it is not important how it works (I believe this idea appeared several times already in this thread). I completely understand the issue of complexity if we test big amout of code referenced by public API, however I believe that in the majority of cases the behavior of each API method is not very complicated and can be tested by few scenarios. At least I haven't seen spec for some method of several pages long :-) Usually the behavior is comparative simple. At the end (but not least important) you have to 'verify' your tests somehow. You prepare them basing on specification, however you should check them on RI. Just to make sure test is correct, spec corresponds to RI, etc. I cannot understand how it could be done for 'internals'... I even know the objections, that only 'public API tests' (in .tests.) should be run on RI. And I even probably agree... Sometimes, it is really desire to write an 'internal' test. For instance, if you use some sorting algoritms, or algoritms which find next match, etc. In this case such 'utility' stuff might be tested independently from the points of usage. However I believe that is not 'general case'. -- Anton Avtamonov, Intel Middleware Products Division
