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 Thanks, Mikhail On 1/29/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > Hi George, > > another example: implementation of SecureRandom might depend on > file:/dev/random > > So, depending on OS, the bytes produced by my implementation of > SecureRandom might be not too random or too secure. > > How do you consider the test that verifies behavior of *my* code > that depends on OS? Is it unit or system? > > Thanks, > Mikhail > > On 1/29/06, George Harley <[EMAIL PROTECTED]> wrote: > > Hi Mikhail, > > > > Comments inlined below. > > > > Best regards, > > George > > IBM UK > > > > > > Mikhail Loenko wrote: > > > Hi Anton, > > > > > > On 1/28/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > > > > > >> On 1/27/06, Anton Avtamonov <[EMAIL PROTECTED]> wrote: > > >> > > >>> Sorry for being away during the major part of your discussion. Hope > > >>> I'm still not too late. > > >>> > > >>> As I can see currently we have only one 'exotic' situation - some > > >>> tests which are based on providers and use so many provider's > > >>> fucntionality that cannot be replaced with mock objects in a > > >>> reasonable time. > > >>> > > > > > > You have only one example, not one situation - there is a difference... > > > <g> > > > > > > > Would you like to give us some more examples ? > > > > > Harmony has a modular structure and final product may be assembled from > > > the modules we can not even think of yet. And the only thing we know about > > > those modules is that they follow the spec. > > > > > > You likely know, security module that does not have any provider or any > > > algorithm implementation follows the spec :). How do you think, will > > > java.util or java.crypto work without those implementations? No. > > > > > > So, following your logic, all unit tests should either do not rely on > > > other modules > > > or include their own implementation of those modules (and better - full > > > J2SE > > > implementation :). > > > > That was not my interpretation of what Anton wrote. What do you consider > > is actually being tested by a unit test ? Is it *just your code* or is > > it *your code plus the system around it* ? I am really keen to hear your > > answer as I think it lies at the very heart of this discussion. > > > > > > > Tests that do not include their own J2SE are system ones, > > > as they rely on environment. > > > > > > > Could you elaborate a bit more on this point please ? > > > > > What I think is we have to be ready that some functionality would be > > > unusable > > > or untestable in some situations and our tests/framework would better > > > be ready for it. > > > > > > > That is a system test issue not a unit test issue. > > > > > Thanks, > > > Mikhail > > > > > > > > > > >
