[classlib][nio]refactor nio buffer's tests

[Paulex Yang <pa...@gmail.com>]

Hi all,

I want to explain what I'm doing on nio modules now, I've raised 
Harmony-575 as the first pilot to refactor the nio buffer's tests, the 
current NIO buffers' test are organized in a very unusual way: test 
logic are written in many static methods, and some instance method 
testXXX call them one by one in sequence. I guess the purpose is to get 
good coverage, there are many kind of buffers hidden in java.nio 
package, and different kind of instances are constructed in different 
ways(wrap, allocate, slice, duplicate, asXXXXBuffer, etc), moreover, the 
buffers can be direct or non-direct, but most of their behavior are 
same, so it is a little tricky on how to coverage all these kinds of 
buffers in test.

But this design have some drawbacks :
1. If one assertion fails, the following ones will not be executed .
2. It is hard to determine the actual position where the failure happens .
3. The codes are difficult to understand or extend, if someone want to 
add one more test method, he may need to add one static method, and add 
the method invocation to some instance testXXX methods.
4. It is not the usual organization for JUnit test suites, and is 
difficult to read and understand

I propose to refactor them to hierarchy, different subclasses only need 
to write a setup() to construct the buffer in different ways, and only 
overrides the test methods if necessary, for example, the hierarchy for 
byte buffer tests are:

AbstractBufferTest
    -- ByteBufferTest
       -- DirectByteBufferTest
             -- DuplicatedDirectBufferTest
             -- ReadOnlyDirectBufferTest
             -- SliceDirectBufferTest
       -- HeapByteBufferTest
             -- ...
       -- WrappedByteBufferTest
             --...

Most test methods locate in AbstractBufferTest and ByteBufferTest, and 
some subclasses like DirectByteBufferTest may override some tests like 
testIsDirect(), but the leaves of the hierarchy probably only needs to 
write a setup(), say, DuplicatedDirectBufferTest may look like:

public class DuplicateDirectByteBufferTest extends DirectByteBufferTest {
    protected void setUp() throws Exception {
        super.setUp();
        buf = buf.duplicate();
    }
}

Harmony-575 is to refactor the ByteBuffer tests, and now I'm trying to 
go on with others, I planned to create one JIRA/patch for one hierarchy, 
i.e., one kind of buffer(character, float, integer...). I'm glad to 
listen to the ideas and comments on this.

-- 
Paulex Yang
China Software Development Lab
IBM



---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org