harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Spark Shen" <smallsmallor...@gmail.com>
Subject Re: [classlib][native-code][test] How about use some unit test tools to write native unit test code?
Date Wed, 24 Jan 2007 08:30:58 GMT
Agree with you that current test case is "porting-guarantee" tests. Not
functional test. And these kinds of test may not need a huge test framework.

But, there are cases where java test is not convenient. For example, file
read/write priviledges on unix like platform to name a few.
Different users with different priviliges will get different testing result
in java.

Test cases written in native C could handle situations like this.

Best regards


2007/1/24, Mark Hindess <mark.hindess@googlemail.com>:
>
>
> On 24 January 2007 at 15:58, "Spark Shen" <smallsmallorgan@gmail.com>
> wrote:
> >
> > Hi All:
> >
> > As I said previously, I want to write some native unit tests. Now, all
> > of the native test code are of the following 2 forms:
> > 1. native mains
> > 2. java mains + jni methods
> >
> > How about introduce some automatic unit test tools such as CUNIT,
> > NUNIT etc into our test framework? Is there any licence problem?
> > AFAIK, CUNIT is of GPL licence and NUNIT is of zlib.
>
> > IMHO, they both are ok.Since we only use them as dll not as source
> > code.  Your opinion?
>
> What are you hoping to test?  I think as much as possible should be
> tested from Java.  I'm only treating the the portlib as "special"
> because that is where the majority of the platform-specific code is (or
> at least should be!).  Thus having portlib tests really helps porting
> when you don't yet have a VME.
>
> I've no objection to using a test framework but I have no experience of
> any of them and they all seemed overkill for my immediate requirements.
> I'll be happy to restructure the current tests to use a framework if we
> find we need one.
>
> Regards,
> Mark.
>
>
>


-- 
Spark Shen
China Software Development Lab, IBM

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message