You are viewing a plain text version of this content. The canonical link for it is here.
Posted to common-issues@hadoop.apache.org by "Jens Rabe (JIRA)" <ji...@apache.org> on 2015/04/20 21:05:58 UTC

[jira] [Updated] (HADOOP-11849) There should be a JUnit test runner which automatically initializes the mini cluster

     [ https://issues.apache.org/jira/browse/HADOOP-11849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jens Rabe updated HADOOP-11849:
-------------------------------
    Description: 
Setting up the mini cluster is not a big deal, but when writing a larger amount of integration tests, one quickly has a lot of code duplication. Creating abstract test classes which set up the cluster is a feasible solution, but then there is the problem with the order of *BeforeClass*, especially when a lengthy MR job is to be run exactly once and several tests then check the output data.

It would be nice if the following were possible:
{code:java}
@RunWith(MiniCluster.class)
public class SomeLengthyIntegrationTest {

  @Conf
  private static Configuration _conf;
  @FS
  private static FileSystem _fs;

  @BeforeClass
  public static void runMRJob() throws Exception {
    final Job job = Job.getInstance(_conf);
    // ... set up the job
    assertTrue("Job was successful", job.waitForCompletion(true));
  }

  @Test
  public void testSomething() {
    // a test
  }

  // more tests
}
{code}

Maybe there could be more annotation-driven configuration options. A nice example for such an approach is the *SpringJUnit4ClassRunner* from the Spring framework.

  was:
Setting up the mini cluster is not a big deal, but when writing a larger amount of integration tests, one quickly has a lot of code duplication. Creating abstract test classes which set up the cluster is a feasible solution, but then there is the problem with the order of *BeforeClass*, especially when a lengthy MR job is to be run exactly once and several tests then check the output data.

It would be nice if the following were possible:
{code:java}
@RunWith(MiniCluster.class)
public class SomeLengthyIntegrationTest {

  @Conf
  private static Configuration _conf;
  @FS
  private static FileSystem _fs;

  @BeforeClass
  public static void runMRJob() throws Exception {
    final Job job = Job.getInstance(_conf);
    // ... set up the job
    assertTrue("Job was successful", job.waitForCompletion(true));
  }

  @Test
  public void testSomething() {
    // a test
  }

  // more tests
}

Maybe there could be more annotation-driven configuration options. A nice example for such an approach is the *SpringJUnit4ClassRunner* from the Spring framework.


> There should be a JUnit test runner which automatically initializes the mini cluster
> ------------------------------------------------------------------------------------
>
>                 Key: HADOOP-11849
>                 URL: https://issues.apache.org/jira/browse/HADOOP-11849
>             Project: Hadoop Common
>          Issue Type: Improvement
>          Components: test
>            Reporter: Jens Rabe
>            Priority: Minor
>
> Setting up the mini cluster is not a big deal, but when writing a larger amount of integration tests, one quickly has a lot of code duplication. Creating abstract test classes which set up the cluster is a feasible solution, but then there is the problem with the order of *BeforeClass*, especially when a lengthy MR job is to be run exactly once and several tests then check the output data.
> It would be nice if the following were possible:
> {code:java}
> @RunWith(MiniCluster.class)
> public class SomeLengthyIntegrationTest {
>   @Conf
>   private static Configuration _conf;
>   @FS
>   private static FileSystem _fs;
>   @BeforeClass
>   public static void runMRJob() throws Exception {
>     final Job job = Job.getInstance(_conf);
>     // ... set up the job
>     assertTrue("Job was successful", job.waitForCompletion(true));
>   }
>   @Test
>   public void testSomething() {
>     // a test
>   }
>   // more tests
> }
> {code}
> Maybe there could be more annotation-driven configuration options. A nice example for such an approach is the *SpringJUnit4ClassRunner* from the Spring framework.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)