Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Hadoop, mail # dev - making a hadoop-common test run if a property is set


Copy link to this message
-
Re: making a hadoop-common test run if a property is set
Tom White 2012-12-17, 16:06
There are some tests like the S3 tests that end with "Test" (e.g.
Jets3tNativeS3FileSystemContractTest) - unlike normal tests which
start with "Test". Only those that start with "Test" are run
automatically (see the surefire configuration in
hadoop-project/pom.xml). You have to run the others manually with "mvn
test -Dtest=...".

The mechanism that Colin describes is probably better though, since
the environment-specific tests can be run as a part of a full test run
by Jenkins if configured appropriately.

Tom

On Mon, Dec 17, 2012 at 10:06 AM, Steve Loughran <[EMAIL PROTECTED]> wrote:
> thanks, I'l; have a look. I've always wanted to add the notion of skipped
> to test runs -all the way through to the XML and generated reports, but
> you'd have to do a new junit runner for this and tweak the reporting code.
> Which, if it involved going near maven source, is not something I am
> prepared to do
>
> On 14 December 2012 18:57, Colin McCabe <[EMAIL PROTECTED]> wrote:
>
>> One approach we've taken in the past is making the junit test skip
>> itself when some precondition is not true.  Then, we often create a
>> property which people can use to cause the skipped tests to become a
>> hard error.
>>
>> For example, all the tests that rely on libhadoop start with these lines:
>>
>> > @Test
>> > public void myTest() {
>> >    Assume.assumeTrue(NativeCodeLoader.isNativeCodeLoaded());
>> >   ...
>> > }
>>
>> This causes them to be silently skipped when libhadoop.so is not
>> available or loaded (perhaps because it hasn't been built.)
>>
>> However, if you want to cause this to be a hard error, you simply run
>> > mvn test -Drequire.test.libhadoop
>>
>> See TestHdfsNativeCodeLoader.java to see how this is implemented.
>>
>> The main idea is that your Jenkins build slaves use all the -Drequire
>> lines, but people running tests locally are not inconvenienced by the
>> need to build libhadoop.so in every case.  This is especially good
>> because libhadoop.so isn't known to build on certain platforms like
>> AIX, etc.  It seems to be a good tradeoff so far.  I imagine that s3
>> could do something similar.
>>
>> cheers,
>> Colin
>>
>>
>> On Fri, Dec 14, 2012 at 9:56 AM, Steve Loughran <[EMAIL PROTECTED]>
>> wrote:
>> > The swiftfs tests need only to run if there's a target filesystem;
>> copying
>> > the s3/s3n tests, something like
>> >
>> >   <property>
>> >     <name>test.fs.swift.name</name>
>> >     <value>swift://your-object-store-herel/</value>
>> >   </property>
>> >
>> > How does one actually go about making junit tests optional in mvn-land?
>> > Should the probe/skip logic be in the code -which can make people think
>> the
>> > test passed when it didn't actually run? Or can I turn it on/off in
>> maven?
>> >
>> > -steve
>>