Re: [classlib][native-code][test] How about use some unit test tools to write native unit test code?

[Mark Hindess <ma...@googlemail.com>]

On 24 January 2007 at 15:58, "Spark Shen" <sm...@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.

Re: [classlib][native-code][test] How about use some unit test tools to write native unit test code?

[Spark Shen <sm...@gmail.com>]

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 <ma...@googlemail.com>:
>
>
> On 24 January 2007 at 15:58, "Spark Shen" <sm...@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

Re: [classlib][native-code][test] How about use some unit test tools to write native unit test code?

[Tim Ellison <t....@gmail.com>]

Mark Hindess wrote:
> On 24 January 2007 at 15:58, "Spark Shen" <sm...@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.

Not only that, but the portlib functions are designed to be called from
C so writing unit tests for them in C makes sense; whereas the Java
natives are designed to be called from Java and you'll have all sorts of
fun setting up the JNIEnv and faking a VM to unit test them from a C
program.

Regards,
Tim

Re: [classlib][native-code][test] How about use some unit test tools to write native unit test code?

["Geir Magnusson Jr." <ge...@pobox.com>]

On Jan 24, 2007, at 3:20 AM, Mark Hindess wrote:

>
> On 24 January 2007 at 15:58, "Spark Shen"  
> <sm...@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.

This is interesting.  I agree that we should test as much with java,  
but it would be good to ensure that we have the necessary unit test  
coverage for the natives.  So instead of hoping the unit tests for  
the SE API are thorough enough, what about writing unit tests in java  
that are designed to test teh portlib and other natives?

The advantage there is that we can use standard test frameworks to do  
this.  downside is, as you point out, what to do when the VM doesn't  
work yet on the new platform.

We do have a test framework in DRLVM for native code, right?

geir


>
> 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.
>
>