harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From George Harley <george.c.har...@googlemail.com>
Subject Re: [testing] code for exotic configurations
Date Sat, 28 Jan 2006 18:57:32 GMT
Hi Mikhail,

Comments inlined below.

Best regards,

Mikhail Loenko wrote:
> Hi Anton,
> On 1/28/06, Mikhail Loenko <mloenko@gmail.com> wrote:
>> On 1/27/06, Anton Avtamonov <anton.avtamonov@gmail.com> 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

View raw message