Annotations

http://junit.sourceforge.net/javadoc/overview-tree.html
o org.junit.Test (implements java.lang.annotation.Annotation) o org.junit.Ignore (implements java.lang.annotation.Annotation) o org.junit.BeforeClass (implements java.lang.annotation.Annotation) o org.junit.Before (implements java.lang.annotation.Annotation) o org.junit.AfterClass (implements java.lang.annotation.Annotation) o org.junit.After (implements java.lang.annotation.Annotation) o org.junit.runner.RunWith (implements java.lang.annotation.Annotation) o org.junit.runners.Suite.SuiteClasses (implements java.lang.annotation.Annotation) o org.junit.runners.Parameterized.Parameters (implements

java.lang.annotation.Annotation)
o org.junit.Rule

Annotation
@ Test

Description
The Test annotation tells JUnit that the public void method to which it is attached can be run as a test case To run the method, JUnit first constructs a fresh instance of the class then invokes the annotated method. Any exceptions thrown by the test will be reported by JUnit as a failure. If no exceptions are thrown, the test is assumed to have succeeded. The Test annotation supports two optional parameters. Test Fixtures A test fixture is a fixed state of a set of objects used as a

Example
The first, expected, declares that a test method should throw an exception. If it doesn't throw an exception or if it throws a different exception than the one declared, the test fails. For example, the following test succeeds: @Test(expected=IndexOutOfBoundsException.class) public void outOfBounds() { new ArrayList<Object>().get(1); }

The second optional parameter, timeout, causes a test to fail if it takes longer than a specified amount of clock time (measured in milliseconds). The following test fails: @Test(timeout=100) public void infinity() { while(true); }

@BeforeClass, @AfterClass, @Before,@After

baseline for running tests

@ Ignore

ignoring tests

@ Rule

Rule Via the @Rule annotatio n you can create objects which can be used and configured in your test methods For specifying test runner

Example of rule: import org.junit.Rule; import org.junit.rules.ExpectedException; many examples are here https://github.com/junitteam/junit/wiki/Rules

@RunWith

@ suiteClasses

@RunWith(Suite.class) @SuiteClasses(ATest.class, BTest.class, CTest.class) public class ABCSuite { }

Test Execution order: Leaves the test methods in the order returned by the JVM. This order may vary from run to run. Sorts the test methods by method name, in lexicographic order

@FixMethodOr der(MethodSort ers.JVM)

@FixMethodOr der(MethodSort ers.NAME_ASC ENDING):

 Test Suit @RunWith(Suite.class) @Suite.SuiteClasses Annotations: @RunWith(Suit.class) @Suite.sutieClasses

Parameterized test import org.junit.runner.RunWith; import org.junit.runners.Parameterized; import org.junit.runners.Parameterized.Parameters; Annotations: @RunWith(Parameterized.class) @Parameters @test

example 1: http://www.vogella.com/articles/JUnit/article.html#installation_junit example 2: https://github.com/junit-team/junit/wiki/Parameterized-tests In order to easily identify the individual test cases in a Parameterized test, you may provide a name using the @Parameters annotation.

Categories @RunWith(Categories.class) @IncludeCategory(SlowTests.class) @ExcludeCategory(FastTests.class) @SuiteClasses( { A.class, B.class }) public class SlowTestSuite { .}

Annotations: @Category @IncludeCategory @ExcludeCategory @ test Either classes or interfaces can be used as categories example: https://github.com/junit-team/junit/wiki/Categories Exception Test: @Test (expected= IndexOutOfBoundsException.class) << passes when an expected exception is thrown Or Expected exception Rule << fails when an unexpected exception is thrown (? I guess)

Observations:
1. JUnit only report the first failure in a single test JUnit is designed to work best with a number of small tests. It executes each test within a separate instance of the test class. It reports failure on each test. Shared setup code is most natural when sharing between tests. for example: One test method, three assertions: is not prefered and not gonna report the fails of each ! instead: Three test methods, one assertion each and use @before for the test setup and @test for each test mothod In my opinion, Junit in this way is enforcing test isolation.

2. using @Before and @After methods to setup per-requisites if any for all your test cases help to make each test independent to all the others the advice for good unit testing practice is : Do not make chain of unit test cases. It will prevent you to identify the root cause of test case failures and you will have to debug the code. Also, it creates dependency, means if you have to change one test case then you need to make changes in multiple testcases unnecessarily. So, in my opinion, using @Before and @After helps to write maintainable test. 3. using @BeforeClass and tell you that the classes under test have some undesirable dependencies it is usually a symptom of excessive coupling in your design.

Refactoring the design to further decouple the classes under test and eliminate code duplication is usually a better investment than setting up a shared test fixture. I think it supports the idea that test reflects the code quality Roy Osherove said it reduced readability as well. Reader will be required to read in tow or three places to be able to understand the test. << don't agree much with the idea I think it helps more with increasing the re-usability of the test Anyway, he recommends to create factories method instead of setup method and call it in each test as a solution. 4. Using annotation is more eye catchy and makes the test more readable. once the reader want look at the test cases, it direct the eyes directly to the @Test annotations then the other annotations comes after that. it makes the tests easy to find. what about how to name the variables unit tests and so on to make it more readable? - need to see examples to be able to answer it Roy Osherove suggest: method name _ state under test _ expected behavior / return value ex: Add_LessThanZero_ThrowsException() Do we need all this part in this name if we are using annotations? or annotations will subtract some of them? >> lead to How annotations affects Naming Convention? " With JUnit 4 (or TestNG) this is longer mandatory and it leaves the developer free to define his own naming convention" This article has discussed the issue fairly well and provided some answers: http://java.dzone.com/articles/unit-test-naming-conventions 5. Paramiterized test: @RunWith(Parameterized.class) @Parameters @test is an effective for reusability tests. Nikolai Tillmann,Wolfram Schulte support it in :Parameterized Unit Tests