From: Stefan Bund Date: Tue, 21 Sep 2010 13:46:59 +0000 (+0200) Subject: initial commit X-Git-Url: http://g0dil.de/git?a=commitdiff_plain;p=java-junit.git initial commit --- f728fccc23a159c0cd9037c5cfd779b726880afd diff --git a/README.html b/README.html new file mode 100644 index 0000000..42f29a6 --- /dev/null +++ b/README.html @@ -0,0 +1,672 @@ + + + + + + + JUnit 4.6 + + + +

+JUnit +4.6

+
Brought to you by Kent Beck, Erich +Gamma, and David Saff. +
FAQ edited by Mike Clark. Web mastering by Erik +Meade. +
(see also JUnit.org) + +
+
6 April 2009 +

JUnit is a simple framework to write repeatable tests. It is an instance +of the xUnit architecture for unit testing frameworks. +

+ + +

Summary of Changes in version 4.6

+ +

Max

+ +

JUnit now includes a new experimental Core, MaxCore. MaxCore +remembers the results of previous test runs in order to run new +tests out of order. MaxCore prefers new tests to old tests, fast +tests to slow tests, and recently failing tests to tests that last +failed long ago. There's currently not a standard UI for running +MaxCore included in JUnit, but there is a UI included in the JUnit +Max Eclipse plug-in at:

+ +

http://www.junitmax.com/junitmax/subscribe.html

+ +

Example:

+ +
public static class TwoUnEqualTests {
+    @Test
+    public void slow() throws InterruptedException {
+        Thread.sleep(100);
+        fail();
+    }
+
+    @Test
+    public void fast() {
+        fail();
+    }
+}
+
+@Test
+public void rememberOldRuns() {
+    File maxFile = new File("history.max");
+    MaxCore firstMax = MaxCore.storedLocally(maxFile);
+    firstMax.run(TwoUnEqualTests.class);
+
+    MaxCore useHistory= MaxCore.storedLocally(maxFile);
+    List<Failure> failures= useHistory.run(TwoUnEqualTests.class)
+            .getFailures();
+    assertEquals("fast", failures.get(0).getDescription().getMethodName());
+    assertEquals("slow", failures.get(1).getDescription().getMethodName());
+}
+
+ +

Test scheduling strategies

+ +

JUnitCore now includes an experimental method that allows you to +specify a model of the Computer that runs your tests. Currently, +the only built-in Computers are the default, serial runner, and two +runners provided in the ParallelRunner class: +ParallelRunner.classes(), which runs classes in parallel, and +ParallelRunner.methods(), which runs classes and methods in parallel.

+ +

This feature is currently less stable than MaxCore, and may be +merged with MaxCore in some way in the future.

+ +

Example:

+ +
public static class Example {
+    @Test public void one() throws InterruptedException {
+        Thread.sleep(1000);
+    }
+    @Test public void two() throws InterruptedException {
+        Thread.sleep(1000);
+    }
+}
+
+@Test public void testsRunInParallel() {
+    long start= System.currentTimeMillis();
+    Result result= JUnitCore.runClasses(ParallelComputer.methods(),
+            Example.class);
+    assertTrue(result.wasSuccessful());
+    long end= System.currentTimeMillis();
+    assertThat(end - start, betweenInclusive(1000, 1500));
+}
+
+ +

Comparing double arrays

+ +

Arrays of doubles can be compared, using a delta allowance for equality:

+ +
@Test
+public void doubleArraysAreEqual() {
+    assertArrayEquals(new double[] {1.0, 2.0}, new double[] {1.0, 2.0}, 0.01);
+}
+
+ +

Filter.matchDescription API

+ +

Since 4.0, it has been possible to run a single method using the Request.method +API. In 4.6, the filter that implements this is exposed as Filter.matchDescription.

+ +

Documentation

+ +
    +

  • A couple classes and packages that once had empty javadoc have been +doc'ed.

    • +

  • Added how to run JUnit from the command line to the cookbook.

    • +

  • junit-4.x.zip now contains build.xml

    • +
+ +

Bug fixes

+ +
    +
  • Fixed overly permissive @DataPoint processing (2191102)
    • +
  • Fixed bug in test counting after an ignored method (2106324)
    • +
+ +

Summary of Changes in version 4.5

+ +

Installation

+ +
    +
  • We are releasing junit-4.6.jar, which contains all the classes +necessary to run JUnit, and junit-dep-4.6.jar, which leaves out +hamcrest classes, for developers who already use hamcrest outside of +JUnit.
    • +
+ +

Basic JUnit operation

+ +
    +

  • JUnitCore now more often exits with the correct exit code (0 for +success, 1 for failure)

    • +

  • Badly formed test classes (exceptions in constructors, classes +without tests, multiple constructors, Suite without @SuiteClasses) +produce more helpful error messages

    • +

  • Test classes whose only test methods are inherited from superclasses +now run.

    • +

  • Optimization to annotation processing can cut JUnit overhead by more than half +on large test classes, especially when using Theories. [Bug 1796847]

    • +

  • A failing assumption in a constructor ignores the class

    • +

  • Correct results when comparing the string "null" with potentially +null values. [Bug 1857283]

    • +

  • Annotating a class with @RunWith(JUnit4.class) will always invoke the +default JUnit 4 runner in the current version of JUnit. This default changed +from JUnit4ClassRunner in 4.4 to BlockJUnit4ClassRunner in 4.5 (see below), +and may change again.

    • +
+ +

Extension

+ +
    +

  • BlockJUnit4Runner is a new implementation of the standard JUnit 4 +test class functionality. In contrast to JUnit4ClassRunner (the old +implementation):

    + +
      +

    • BlockJUnit4Runner has a much simpler implementation based on +Statements, allowing new operations to be inserted into the +appropriate point in the execution flow.

      • +

    • BlockJUnit4Runner is published, and extension and reuse are +encouraged, whereas JUnit4ClassRunner was in an internal package, +and is now deprecated.

      • +
    • +

  • ParentRunner is a base class for runners that iterate over +a list of "children", each an object representing a test or suite to run. +ParentRunner provides filtering, sorting, @BeforeClass, @AfterClass, +and method validation to subclasses.

    • +

  • TestClass wraps a class to be run, providing efficient, repeated access +to all methods with a given annotation.

    • +

  • The new RunnerBuilder API allows extending the behavior of +Suite-like custom runners.

    • +

  • AssumptionViolatedException.toString() is more informative

    • +
+ +

Extra Runners

+ +
    +

  • Parameterized.eachOne() has been removed

    • +

  • New runner Enclosed runs all static inner classes of an outer class.

    • +
+ +

Theories

+ +
    +

  • @Before and @After methods are run before and after each set of attempted parameters +on a Theory, and each set of parameters is run on a new instance of the test class.

    • +

  • Exposed API's ParameterSignature.getType() and ParameterSignature.getAnnotations()

    • +

  • An array of data points can be introduced by a field or method +marked with the new annotation @DataPoints

    • +

  • The Theories custom runner has been refactored to make it faster and +easier to extend

    • +
+ +

Development

+ +
    +

  • Source has been split into directories src/main/java and +src/test/java, making it easier to exclude tests from builds, and +making JUnit more maven-friendly

    • +

  • Test classes in org.junit.tests have been organized into +subpackages, hopefully making finding tests easier.

    • +

  • ResultMatchers has more informative descriptions.

    • +

  • TestSystem allows testing return codes and other system-level interactions.

    • +
+ +

Summary of Changes in version 4.4

+ +

JUnit is designed to efficiently capture developers' intentions about +their code, and quickly check their code matches those intentions. +Over the last year, we've been talking about what things developers +would like to say about their code that have been difficult in the +past, and how we can make them easier.

+ +

assertThat

+ +

Two years ago, Joe Walnes built a new assertion mechanism on top of what was +then JMock 1. The method name was assertThat, and the syntax looked like this:

+ +
assertThat(x, is(3));
+assertThat(x, is(not(4)));
+assertThat(responseString, either(containsString("color")).or(containsString("colour")));
+assertThat(myList, hasItem("3"));
+
+ +

More generally:

+ +
assertThat([value], [matcher statement]);
+
+ +

Advantages of this assertion syntax include:

+ + + +

We have decided to include this API directly in JUnit. +It's an extensible and readable syntax, and because it enables +new features, like assumptions and theories.

+ +

Some notes:

+ + + +

assumeThat

+ +

+Ideally, the developer writing a test has control of all of the forces that might cause a test to fail. +If this isn't immediately possible, making dependencies explicit can often improve a design.
+For example, if a test fails when run in a different locale than the developer intended, +it can be fixed by explicitly passing a locale to the domain code.

+ +

However, sometimes this is not desirable or possible.
+It's good to be able to run a test against the code as it is currently written, +implicit assumptions and all, or to write a test that exposes a known bug. +For these situations, JUnit now includes the ability to express "assumptions":

+ +
import static org.junit.Assume.*
+
+@Test public void filenameIncludesUsername() {
+   assumeThat(File.separatorChar, is('/'));
+   assertThat(new User("optimus").configFileName(), is("configfiles/optimus.cfg"));
+}
+
+@Test public void correctBehaviorWhenFilenameIsNull() {
+   assumeTrue(bugFixed("13356"));  // bugFixed is not included in JUnit
+   assertThat(parse(null), is(new NullDocument()));
+}
+
+ +

With this beta release, a failed assumption will lead to the test being marked as passing, +regardless of what the code below the assumption may assert. +In the future, this may change, and a failed assumption may lead to the test being ignored: +however, third-party runners do not currently allow this option.

+ +

We have included assumeTrue for convenience, but thanks to the +inclusion of Hamcrest, we do not need to create assumeEquals, +assumeSame, and other analogues to the assert* methods. All of +those functionalities are subsumed in assumeThat, with the appropriate +matcher.

+ +

A failing assumption in a @Before or @BeforeClass method will have the same effect +as a failing assumption in each @Test method of the class.

+ +

Theories

+ +

+More flexible and expressive assertions, combined with the ability to +state assumptions clearly, lead to a new kind of statement of intent, +which we call a "Theory". A test captures the intended behavior in +one particular scenario. A theory allows a developer to be +as precise as desired about the behavior of the code in possibly +infinite numbers of possible scenarios. 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 user's filename 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 DataPoint 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.

+ +

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

+ +

Defining general statements in this way can jog the developer's memory +about other potential data points and tests, also allows automated +tools to search for new, unexpected data +points that expose bugs.

+ +

Other changes

+ +

This release contains other bug fixes and new features. Among them:

+ + + +

+Summary of Changes in version 4.3.1

+

+

+

+ +

+Summary of Changes with version 4.3

+

+

+

+ +

+Summary of Changes with version 4.2

+

+

+

+ + +

+Summary of Changes with version 4.1

+

+

+

+ +

Summary of Changes with version 4.0

+

+The architecture of JUnit 4.0 is a substantial departure from that of earlier releases. +Instead of +tagging test classes by subclassing junit.framework.TestCase and tagging test methods by +starting their name with "test", you now tag test methods with the @Test annotation. +

+ + +

+Contents of the Release

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
README.html this file
junit-4.6.jara jar file with the JUnit framework, bundled with the hamcrest-core-1.1 dependency.
junit-dep-4.6.jara jar file with the JUnit framework, unbundled from any external dependencies. +Choosing to use this jar developers will need to also provide in the classpath a compatible version of external dependencies (ie hamcrest-core-1.1+)
junit-4.6-src.jara jar file with the source code of the JUnit framework
org/junitthe source code of the basic JUnit annotations and classes
    samplessample test cases
    teststest cases for JUnit itself
javadocjavadoc generated documentation
docdocumentation and articles
+ +

+Installation

+Below are the installation steps for installing JUnit: +
    +
  1. +unzip the junit4.6.zip file
    2. + +
  2. +add junit-4.6.jar to the CLASSPATH. For example: + set classpath=%classpath%;INSTALL_DIR\junit-4.6.jar;INSTALL_DIR
    3. + +
  3. +test the installation by running java org.junit.runner.JUnitCore org.junit.tests.AllTests
    4. + +
    Notice: that the tests are not +contained in the junit-4.6.jar but in the installation directory directly. +Therefore make sure that the installation directory is on the class path +
+Important: don't install junit-4.6.jar +into the extension directory of your JDK installation. If you do so the +test class on the files system will not be found. +

+Getting Started

+To get started with unit testing and JUnit read the article: +JUnit Cookbook. +
This article describes basic test writing using JUnit 4. +

You find additional samples in the org.junit.samples package: +

+ +

+Documentation

+ +
JUnit Cookbook +
    A cookbook for implementing tests with JUnit. +
Javadoc +
    API documentation generated with javadoc. +
Frequently asked questions +
    Some frequently asked questions about using JUnit. +
License +
    The terms of the common public license used for JUnit.
+
+The following documents still describe JUnit 3.8. +
+
Test Infected - Programmers +Love Writing Tests +
    An article demonstrating the development process +with JUnit. +
JUnit - A cooks tour +
+ +
+SourceForge Logo + + diff --git a/junit-4.8.2.jar b/junit-4.8.2.jar new file mode 100644 index 0000000..5b4bb84 Binary files /dev/null and b/junit-4.8.2.jar differ diff --git a/junit-dep-4.8.2.jar b/junit-dep-4.8.2.jar new file mode 100644 index 0000000..f28b4ef Binary files /dev/null and b/junit-dep-4.8.2.jar differ