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

2007-01-29 Thread Tim Ellison
Mark Hindess wrote:
> On 24 January 2007 at 15:58, "Spark Shen" <[EMAIL PROTECTED]> 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?

2007-01-24 Thread Geir Magnusson Jr.


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



On 24 January 2007 at 15:58, "Spark Shen"  
<[EMAIL PROTECTED]> 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.






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

2007-01-24 Thread Spark Shen

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 <[EMAIL PROTECTED]>:



On 24 January 2007 at 15:58, "Spark Shen" <[EMAIL PROTECTED]>
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?

2007-01-24 Thread Mark Hindess

On 24 January 2007 at 15:58, "Spark Shen" <[EMAIL PROTECTED]> 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.