avro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Boudnik <...@yahoo-inc.com>
Subject Re: TestNG in Avro [Was: Code reorg]
Date Mon, 04 May 2009 19:15:56 GMT
It turns out that the issues were caused by this inheritance

public class TestProtocolReflect extends TestProtocolSpecific

where TestProtocolSpecific was declaring testStartServer() method as 
@BeforeMethod and TestProtocolReflect has it has just @Test

When using @Before.../@After annotations the overall number of tests was 
reduced to 34 from 42 because none of @Before.../@After accounted as 
tests anymore.

Resolved and new patch is submitted. Review is highly welcomed! :-)

Konstantin Boudnik wrote:
> Thanks for the info, Doug.
> The failures were caused by these two issues:
>    - the presence of generated Test interface which was clashing with 
> org.testng.annotations.Test. To work around the problem I have renamed 
> test.js to generated.js and refactored all code, which has been affected 
> by this
>    - RPC testing sequence as you've described below. After I've realized 
> that certain tests require a server to be started upfront the rest of 
> exercise was a breeze. I've put inter tests dependencies so the 
> testStartServer() would be always called before any of the test methods 
> is started.
> Both of these modifications are included into the AVRO-26 patch.
> Just now I have thought and tried another approached to guarantee 
> execution sequence for RPC tests: I've added @BeforeMethod and 
> @AfterMethod annotations to testStartServer() and testStopServer() 
> respectively and removed hardcoded inter-tests dependencies. This 
> approach has worked for at least two complex test classes: 
> TestProtocolGeneric and TestFsData. In TestProtocolSpecific class
> this approach failed and I'll take a look to find out why it is so.
> I think technically AVRO is ready to be switched to TestNG for all 
> current java tests are converted into the new framework.
> Cos
> Doug Cutting wrote:
>> Konstantin Boudnik wrote:
>>>   1) Complete test conversion using provided JUnitConverter. For a 
>>> number of reasons it failed to work. One of the possible reasons my 
>>> insufficient TestNG skills. Another possible reason is relative 
>>> complexity of the tests, which is above JUnitConverter level of intellect.
>> How did it fail?
>> Most of the tests don't push JUnit very hard and should be trivial.  The 
>> only one's that I'd expect to be a problem are the RPC tests.  I tried 
>> to use JUnit's setup/teardown methods to start and stop the daemon, but 
>> could not get that to work for some reason.  I ended up doing something 
>> pretty ugly, which is, in each class, adding an initial test method that 
>> starts a daemon, and a final one that kills the daemon, and a bunch in 
>> between that use the daemon for tests.  So perhaps the problem is 
>> related to this, e.g., perhaps JUnitConverter doesn't run tests in the 
>> right order or somesuch.
>> Doug

View raw message