Home
Categories
Dictionary
Download
Project Details
Changes Log
FAQ
License

junit


    1  Ordering Unit Tests
       1.1  Example
    2  Group Unit Tests classes in Categories
       2.1  Discovering categories
          2.1.1  Discovering the categories file
          2.1.2  File structure
          2.1.3  StrictMode
          2.1.4  ShowSkippedClasses
          2.1.5  Managing the discovery
          2.1.6  Examples
       2.2  Example
    3  Notes

The junit package contains several utilities useful when developing Unit tests with the JUnit.

This package allows to:
  • Order Unit Tests methods runs[1]
    By default beginning with Java 7 the order of runs of Unit tests methods is not consistent with the order on which the methods are defined in the source file. This is because methods in the associated .class file can be reordered for performance reasons (keep in mind than the JVM specification never specified that the order of methods in the source file should be kept in the .class file)
    [2]
    In the last version of JUnit the Unit Tests can be ordered by themethods names, which is not always convenient
  • Group Unit Tests classes in Categories, and allow to configure which categories will be run

Ordering Unit Tests

To order Unit Tests methods in a Unit Test class, you have to:
  • Annotate the Unit test class with the OrderedRunner annotation
  • Annotate each methods in the Unit Test class with the Order annotation
If you execute the Unit Test class in a JavaFX environment you should rather annonate the class with the OrderedJavaFXRunner annotation. Note that an OrderedRunner is also a CategoryRunner .

Example

If a test class has the two following methods:
   public class MyTest {

   @Test
   public void test1() {
   ...
   }

   @Test
   public void test2() {
   ...
   }
Nothing prevents the tests to be executed in the order test2() then test1(). To ensure that the order will be test1() then test2(), you can use:
   @RunWith(OrderedRunner.class)
   public class MyTest {

   @Test
   @Order(order=1)
   public void test1() {
   ...
   }

   @Test
   @Order(order=2)
   public void test2() {
   ...
   }

Group Unit Tests classes in Categories

To specify the categories on which a Unit Test belongs to, you should:
  • Annotate the Unit test class with the CategoryRunner annotation
  • Add an Category annotation for each category the Test Clas belongs to

Discovering categories

Discovering the categories file

To execute the Unit Tests which belong to one or several categories, you should put a categories.properties file in a org.mdiutil.junit.resources package in your unit tests directory[3]
Note that before the version 0.9.16, thecategories.properties file was discovered in the org.mdiutils.junit.resources package
.

For example on NetBeans you could have the following package structure:
      test
      ==> my
      ====> package
      MyFirstTest.java
      MySecondTest.java
      org
      ==> mdiutils
      ====> junit
      ======> resources
      categories.properties

File structure

The categories.properties file is a properties file with (key, value) pairs:
  • The key is the category name
  • The value is true or false: true indicates that the tests of the specified category should run, false that they should not run
Note that if no values are defined, all Unit tests will be run.

StrictMode

If the "strictMode" value is true, only tests which belong to all "true" categories will be executed. For example:
   strictMode=true
   editor=
   server=
   client=false
Only Unit Tests annotated by both "editor" and "server" will run.

ShowSkippedClasses

If the "showSkippedClasses" value is true, tests which are not executed will be set as Ignored[4]
See the Ignore Junit API
. For example:
   showSkippedClasses=true
   editor=
   server=
   client=false
If "showSkippedClasses" value is false, then tests which are not executed will not be shown at all.

Note that by default showSkippedClasses is set as true. For example, in Netbeans, you would see this when executing the tests of the MDIUtilities project with the following configuration:
   strictMode=false
   long=
   pack=
   archi=false

junitskip

Managing the discovery

It is not possible easily in JUnit 4 to keep the value of a computation between two different Unit Test classes. However the categories are defined in a properties file.

To avoid to perform the same parsing for each Unit test class, the parsing of the categories.properties file is performed only for the first categorized Unit test class. For all subsequent Unit Test classes, the value of the categories to run will be memorized in a system environment variable called MDIUTILITIES_JUNIT_ENV environment variable and reused for all the Unit tests classes.

Examples

  editor=
  server=
  client=
All Unit Tests will run.

   editor=true
   server=false
   client=false
Only "editor" Unit Tests will run.

   editor=
   server=
   client=false
All Unit Tests except "client" Unit tests will run.

   strictMode=true
   editor=true
   server=true
   client=
Only Unit Tests annotated by both "editor" and "server" will run.

Example

  @RunWith(CategoryRunner.class)
  @Category(cat="editor")
  @Category(cat="server")
  public class MyTest {

  @Test
  public void test1() {
  ...
  }

  @Test
  public void test2() {
  ...
  }
In this case, the MyTest class belong to two categories:
  • "editor"
  • "server"

Notes

  1. ^ By default beginning with Java 7 the order of runs of Unit tests methods is not consistent with the order on which the methods are defined in the source file. This is because methods in the associated .class file can be reordered for performance reasons (keep in mind than the JVM specification never specified that the order of methods in the source file should be kept in the .class file)
  2. ^ In the last version of JUnit the Unit Tests can be ordered by themethods names, which is not always convenient
  3. ^ Note that before the version 0.9.16, thecategories.properties file was discovered in the org.mdiutils.junit.resources package
  4. ^ See the Ignore Junit API

Categories: packages

Copyright 2006-2024 Herve Girod. All Rights Reserved. Documentation and source under the LGPL v2 and Apache 2.0 licences