Package org.junit.experimental.theories

Class Theories

  • All Implemented Interfaces:
    Describable, Filterable, Orderable, Sortable
    public class Theories
extends BlockJUnit4ClassRunner
    The Theories runner allows to test a certain functionality against a subset of an infinite set of data points.

    A Theory is a piece of functionality (a method) that is executed against several data inputs called data points. To make a test method a theory you mark it with @Theory. To create a data point you create a public field in your test class and mark it with @DataPoint. The Theories runner then executes your test method as many times as the number of data points declared, providing a different data point as the input argument on each invocation.

    A Theory differs from standard test method in that it captures some aspect of the intended behavior in possibly infinite numbers of scenarios which corresponds to the number of data points declared. Using assumptions and assertions properly together with covering multiple scenarios with different data points can make your tests more flexible and bring them closer to scientific theories (hence the name).

    For example: 

    
 @RunWith(Theories.class)
 public class UserTest {
      @DataPoint
      public static String GOOD_USERNAME = "optimus";
      @DataPoint
      public static String USERNAME_WITH_SLASH = "optimus/prime";

      @Theory
      public void filenameIncludesUsername(String username) {
          assumeThat(username, not(containsString("/")));
          assertThat(new User(username).configFileName(), containsString(username));
      }
 }
    This makes it clear that the username should be included in the config file name, only if it doesn't contain a slash. Another test or theory might define what happens when a username does contain a slash. UserTest will attempt to run filenameIncludesUsername on every compatible data point defined in the class. If any of the assumptions fail, the data point is silently ignored. If all of the assumptions pass, but an assertion fails, the test fails. If no parameters can be found that satisfy all assumptions, the test fails.

    Defining general statements as theories allows data point reuse across a bunch of functionality tests and also allows automated tools to search for new, unexpected data points that expose bugs.

    The support for Theories has been absorbed from the Popper project, and more complete documentation can be found from that projects archived documentation.

    See Also:
    Archived Popper project documentation, Paper on Theories

    • Method Detail

      • methodBlock

        public Statement methodBlock​(FrameworkMethod method)
        Description copied from class: BlockJUnit4ClassRunner
        Returns a Statement that, when executed, either returns normally if method passes, or throws an exception if method fails. Here is an outline of the default implementation:
        • Invoke method on the result of BlockJUnit4ClassRunner.createTest(org.junit.runners.model.FrameworkMethod), and throw any exceptions thrown by either operation.
        • HOWEVER, if method's @Test annotation has the Test.expected() attribute, return normally only if the previous step threw an exception of the correct type, and throw an exception otherwise.
        • HOWEVER, if method's @Test annotation has the timeout attribute, throw an exception if the previous step takes more than the specified number of milliseconds.
        • ALWAYS run all non-overridden @Before methods on this class and superclasses before any of the previous steps; if any throws an Exception, stop execution and pass the exception on.
        • ALWAYS run all non-overridden @After methods on this class and superclasses after any of the previous steps; all After methods are always executed: exceptions thrown by previous steps are combined, if necessary, with exceptions from After methods into a MultipleFailureException.
        • ALWAYS allow @Rule fields to modify the execution of the above steps. A Rule may prevent all execution of the above steps, or add additional behavior before and after, or modify thrown exceptions. For more information, see TestRule
        This can be overridden in subclasses, either by overriding this method, or the implementations creating each sub-statement.
        Overrides:
        methodBlock in class BlockJUnit4ClassRunner