removing redundant asserts
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
Merge pull request #178 from abyx/master

Simple removal of (seemingly) redundant asserts
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
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
Merge pull request #362 from nkeywal/eb307fa6f37ac8ec695b2f556e543969503418f5

Fix for #359
The runner adds the square brackets to the name.
Apply code review.
Use SecurityManager recommended by Stefan Birkner
Don't remove listeners, which throw exceptions (fixes #209 and #395)
RunNotifier.pleaseStop() is now thread-safe