Agree with Jeremy's comments. I don't think the unit tests should be advertised or seen as a guide to using the API at a system or functional level. Their purpose is simply to test the methods under test, using the minimum necessary preconfiguration to accurately test the methods' normal (and abnormal) behaviour. +1 to your point about constructors. If the ctors are available internally then they certainly should be available to the white-box tester.
Probably plenty of scope for discussion here, and reviews would be good for that. Kind Regards, Graham. _____________________________________________ Graham C Turrell CEng, MBCS Chartered IT Practitioner WebSphere ESB Foundation Technologies DE3F16 / MP 211 IBM Labs Hursley Park Winchester, Hampshire England. SO21 2JN Tel +44-(0)1962-815018 email: [EMAIL PROTECTED] "No army can withstand the force of an idea whose time has come.". -Victor Hugo [EMAIL PROTECTED] wrote on 29/01/2007 09:38:07: > On 29/01/07, John Kaputin <[EMAIL PROTECTED]> wrote: > [...] > > Many of the Woden unit tests do use impl classes directly, violating the > > Woden API. I've even written some of these myself! This was done for > > convenience originally - short cuts when creating tests, but as Woden has > > evolved it has become more important to use the API correctly. These unit > > tests don't actually break, either because setters have been used to > > correctly initialize them or because they don't exercise the code paths > > that might cause problems when not correctly initialized. However, as > > users may end up looking at the test cases for coding examples I think we > > should review them and change them to use the API where it's easy to do so. > > +1 to that. > > > And document the exceptions if there are any (e.g. it might just be easier > > in some cases to set up a complex test case programmatically by using > > non-API techniques). > > wouldn't that mean users have an excuse to do the same. 'White box' > unit tests should be allowed to use ctors - we could document these > tests as such and discourage users to copy the code. > > Cheers, > Jeremy > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
