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: