On 1/30/06, Anton Avtamonov <[EMAIL PROTECTED]> wrote: > On 1/29/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > > P.S. There are also 'integration' tests that verify how different 'units' > > work together. > > > > I think the areas of various tests intersect and it would be good to define > > them on this early stage > > > > Well, agree. And I think our discussion is exactly about to define > what is right unit, integration and system testing. > > Talking about how real unit test should be prepared I'd like to give > some example:
I like examples :) > > There is a method java.awt.Toolkit.getDefaultToolkit().getScreenSize() > which returns the current screen size. > Let's assume there is some functionality which works differently > depending on actual screen size. You are going to test that > functionality. > The first approach (as I understand that is what you are using) is to: > - if the screen resolution is as expected - do testing > - otherwise skip the test. > > Another approach (which I think to be more appropriate) is: > - override getScreenSize() method of some 'TestToolkit' and install it > as 'default toolkit' in the test setUp, so that it returns the desired > value for the particular test. > This gives me an ability to write all necessary tests and cover all > the paths of my functionality which depend on screen size. Well, getScreenSize() returns a number, and it is possible to loop through valid (and some invalid but possible) values and test with them. But what if the method returns an AlgorithmParameters *implementation* or a certificate in encoded form (which is byte array)? Thanks, Mikhail. > > Note that I'm not going to re-create all other classes of JSEE :-). I > need to control getScreenSize() only and have to create the required > mock-object to achieve that. > > -- > Anton Avtamonov, > Intel Middleware Products Division >
