JUnit Design Goals
The JUnit team has defined three discrete goals for the framework:
  The framework must help us write useful tests.
  The framework must help us create tests that retain their value over time.
  The framework must help us lower the cost of writing tests by reusing code.

When it is easy to reuse a fixture between tests, you can write tests more
quickly. Each time you reuse the fixture, you decrease the initial investment
made when the fixture was created. The TestCase fixtures speak to JUnit’s
third design goal:
The framework must lower the cost of writing tests by reusing code.

The simple but effective combination of a TestRunner with a TestSuite
makes it easy to run all your tests every day. At the same time, you can select a
subset of tests that relate to the current development effort. This speaks to
JUnit’s second design goal:
The framework must create tests that retain their value over time.
When you continue to run your tests, you minimize your investment in testing
and maximize your return on that investment.

Keeping tests independent
As you begin to write your own tests, remember the first rule: Each unit test must
run independently of all other unit tests. Unit tests must be able to be run in any order.
One test must not depend on some side effect caused by a previous test (for example,
a member variable being left in a certain state). If tests begin to depend on
one another, you are inviting trouble. Here are some of the problems with codependent
tests: 
     Not portable—By default, JUnit finds test methods by reflection. The reflection
API does not guarantee an order in which it returns the method names.
If your tests depend on an ordering, then your suite may work in one Java
Virtual Machine (JVM) but fail in another.
     Hard to maintain—When you modify one test, you may find that a number of
other tests are affected. If you need to change the other tests, you spend
time maintaining tests—time that could have been spent developing code.
     Not legible—To understand how co-dependent tests work, you must understand
how each one works in turn. Tests become more difficult to read and
harder to maintain. A good test must be easy to read and simple to maintain.

Three flavors of unit tests: logic, integration, and functional

• Logic unit tests

Unit tests that focus on exercising the code logic. These tests are usually meant to exercise only a single method and no other. You can control the boundaries of a given method using mock objects or stubs.

• Integration unit tests

Unit tests that focus on testing the interaction between components in their real
environment (or part of the real environment). For example, code that accesses a database has tests that effectively call the database, thus proving that the codedatabase interaction works.

• Functional unit tests

Unit tests that extend the boundaries of integration unit testing to confirm a
stimulus-response. For example, imagine a web page that is protected and that
you can access only after being logged in. If you are not logged in, accessing the page results in a redirect to the login page. A functional unit test verifies that
behavior by sending an HTTP request to the page and verifying that the result is a 302 response code. It does not, however, verify that the full workflow leads to
the login page. Workflow is the domain of pure, software functional testing.