removing redundant asserts
Adding assertNotEquals to Object, long and double
Fixes gh-121 (ExpectedException handles JUnit exceptions)

ExpectedException rule no longer handles AssertionErrors and
AssumptionViolatedExceptions by default. This means that the
rule doesn't intercept if your test fails because of an violated
assertion or assumption.

If you want to test assertions or assumptions you have to tell
the rule to handle such exceptions via handleAssertionErrors()
or handleAssumptionViolatedExceptions().
deleted duplicate EventCollector
the two handle... methods are returning the rule

The two methods handleAssertionError() and
handleAssumptionViolatedExceptions() are returning the rule.

Now you can write
  @Rule
  public ExpectedException thrown = none().handleAssertionError();
or
  @Rule
  public ExpectedException thrown = none().handleAssumptionViolatedExceptions()

Thank you David, for this suggestion.
Fix for #359
Improved Description class.

A few modifications to improve the readability of the code:
* extracted METHOD_AND_CLASS_NAME_PATTERN constant
* extracted methodAndClassNamePatternGroupOrDefault(...)
* merged getMethodName() and parseMethod()
* moved validation of display name to constructor
* throw IllegalArgumentException if display name is null
Added MainRunner. This removes the need for public methods in JUnitCore
MainRunner installs a SecurityManager which traps the System.exit(), thereby
removing the need to have runMainAndExit and runMain public in JUnitCore.
MainRunner is only used in the tests of course.
Several javadoc referred to MethodRule when they should have referred to TestRule
Simplifying isEqualsRegardingNull.
Removed offending @Override annotation (#382)
Timeout exception contains the real cause of the timeout (#384)
Merge pull request #178 from abyx/master

Simple removal of (seemingly) redundant asserts
Improved failure message (#384)
SortMethodsWith allows the user to choose the order of execution of the methods within a test class.

The default order of execution of JUnit tests within a class
is deterministic but not predictable. Before 4.11, the
behaviour was to run the test methods in byte code order,
which pre-Java 7 was mostly predictable. Java 7 (and some
previous versions), does not guaranteee the order of execution,
which can change from run to run, so a deterministic sort was introduced.
As a rule, test method execution should be independent of
one another. However, there may be a number of dependent
tests either through error or by design. This class
allows the user to specify the order of execution of test methods.

There are four possibilities:

MethodSorters.DEFAULT: the default value, deterministic, but not predictable
MethodSorters.JVM: the order in which the tests are returned by the JVM, i.e. there is no sorting done
MethodSorters.NAME_ASC: sorted in order of method name, ascending
MethodSorters.NAME_DESC: sorter in order of method name, descending
Improved failure message (#384)
Merge pull request #365 from stefanbirkner/cleanjunit

Improved Description class
Merge pull request #372 from matthewfarwell/doc-methodrule

Several javadoc referred to MethodRule when they should have referred to...
Add names for parameterized tests. Fixes #24 and #44.

In order that you can easily identify individual test, you may provide
a name for the Parameters annotation.
 @Parameters(name="my test")
This name is allowed to contain placeholders, which are replaced at
runtime. The placeholders are
* {index} - the current parameter index
* {0} - the first parameter
* {1} - the second parameter
* ... - the other parameters
If you don't use the name parameter, then the current parameter index
is used as name.

Example:
When you use @Parameters(name="fib({0})={1}") with the Fibonacci
example, then you get test names like "fib(3)=2".

This feature is based on the work of Dimitar Dimitrov (pull request
#145).
Thank
you.
Don't use static import for MessageFormat.format