JUnit, Maven - Unit testing Java Code

Ok I got my app up and running ready to fire and forget.. or am I?

You should clarify your question to define what is meant with "start testing".
Take a look on this diagram :

There are various aspects of tests.

They are defined and run at all phases across Software Development Life Cycle (SDLC):

• Acceptance Tests are defined just at the same time with Business Requirements - e.g. they are defined at the very beginning of an SDLC and run at the very end;
• System Tests are defined along with SRS and are usually run for each alpha/local release;
• Integration Tests are "mid-range" tests for components; They are defined and run pretty often, e.g. on weekly scrums;
• and so on, till the very low-level Unit Tests that are defined and run on practically the same time;

Moreover there are tests like

• behavioral tests (BDD)
• mutation tests - made to test if existing tests are picking the improper states of a tested software. IE. check if tests are correct and sufficiently cover the requirements that have originated the implementation.

So the answer to the question is:

You should define and run different types of your tests at all phases of entire SDLC.
Actually there is a whole technique of software development based on tests that are used to specify the requirements that should be met by the developed app code. It is called Test Driven Development (TDD) and will be covered in following articles.

Here is a brief teaser of TDD from Marcin 

What are the unit tests? 

Every software that is being developed can be divided into many small bricks that builds it. Each brick i.e. a simple piece of code has its input and its output values. Regarding Java the code is divided into classes with methods. Thus it is reasonable to consider a method as a code unit that has its IN/OUT results. Even in case of void class it has its programmed behavior changing a state, that we can consider as a result.
As we consider the unit tests the smallest unit of code that each unit test target is a method (or a class).

The tests are extra classes end methods to ensure that actual code works as intended.

The more part of the application has tests the bigger test coverage it gets and more stable it gets.

The tests however, are not part of the source code and therefore they reside in their own directory or even project. While developing the app with maven archetypes most of them cover the following directory/package structure:

my-app 
|-- pom.xml
`-- src
    |-- main
    |   `-- java
    |       `-- com
    |           `-- mycompany
    |               `-- app
    |                   `-- App.java
    `-- test
        `-- java
            `-- com
                `-- mycompany
                    `-- app
                        `-- AppTest.java

JUnit - framework for unit testing

The JUnit is one of the most popular frameworks that makes unit testing simple and robust.

Along the use of JUnit we will be basing on two major concepts i.e. annotations and static methods in form of assertions. Both are part of JDK and are widely used along Java environment.
JUnit is provides us with its own set of annotations and assertions.

Adding JUnit to our Maven Project.

Installation of JUnit is as simple as adding the maven dependency regardless of IDE :

<dependency>
  <groupId>junit</groupId>
  <artifactId>junit</artifactId>
  <version>4.11</version>
  <scope>test</scope>
</dependency> 

Now running the potential tests using plain console maven syntax is straightforward.
 

mvn test

JUnit testing basics

To create a simple test first let us explain how to point what part of code do we want to test and what are expected conditions to be fulfilled by the tested code.

1. Annotations: How to establish the tested code?
   
   We now know that test as a code has separate folder. Now let us mark each testing method. JUnit uses annotations to identify methods that specify a test. In general these test methods are contained in a class which is only used for testing, also known a Test class. The testing method will be pointed with the @org.junit.Test annotation and must be a public method.
   Below we present the basic annotations:
   

   Annotation	Description
   @Test public void method()	The @Test annotation identifies a method as a test method.
   @Test (expected = Exception.class)	Fails, if the method does not throw the named exception.
   @Test(timeout=100)	Fails, if the method takes longer than 100 milliseconds.
   @Before public void method()	This method is executed before each test. It is used to can prepare the test environment (e.g. read input data, initialize the class).
   @After public void method()	This method is executed after each test. It is used to cleanup the test environment (e.g. delete temporary data, restore defaults). It can also save memory by cleaning up expensive memory structures.
   @BeforeClass public static void method()	This method is executed once, before the start of all tests. It is used to perform time intensive activities, for example to connect to a database. Methods annotated with this annotation need to be defined as static to work with JUnit.
   @AfterClass public static void method()	This method is executed once, after all tests have been finished. It is used to perform clean-up activities, for example to disconnect from a database. Methods annotated with this annotation need to be defined as static to work with JUnit.
   @Ignore	Ignores the test method. This is useful when the underlying code has been changed and the test case has not yet been adapted. Or if the execution time of this test is too long to be included.

   
   
   
2. Assertions: How to setup test expectations and conditions?
   
   Now that we know which method will be the testing method we have to check the expected result of the code execution versus the actual result. For this we will utilize a method provided by JUnit in for of assertion methods. The assertion methods provided by JUnit allows to specify an expected result, the actual outcome of the tested method and an error message. The assertion is used here to compare the actual returned value to the expected one and to produce an error in case this comparison fails.
   This is important to remember that assertion should NOT be left in production code. It is made for tests and thus should be present only in this stage of development.
   
   Here is a brief explanation of some of the assertion methods:
   
   

   Statement	Description
   fail(String)	Let the method fail. Might be used to check that a certain part of the code is not reached. Or to have a failing test before the test code is implemented. The String parameter is optional.
   assertTrue([message], boolean condition)	Checks that the boolean condition is true.
   assertFalse([message], boolean condition)	Checks that the boolean condition is false.
   assertEquals([String message], expected, actual)	Tests that two values are the same. Note: for arrays the reference is checked not the content of the arrays.
   assertEquals([String message], expected, actual, tolerance)	Test that float or double values match. The tolerance is the number of decimals which must be the same.
   assertNull([message], object)	Checks that the object is null.
   assertNotNull([message], object)	Checks that the object is not null.
   assertSame([String], expected, actual)	Checks that both variables refer to the same object.
   assertNotSame([String], expected, actual)

At this moment we know that each method in application code can have a test methods that can check tested method behavior for given input conditions. However there is one important rule:

Each method can be called in arbitrary order so tests must NOT depend on each other's result.

 JUnit basic examples

• Simple Test annotation:
  
  

  @Test
  public void testIndexOutOfBoundsException() {
    try {
      List list = new ArrayList();
      list.get(1);
      fail("Expected exception throw IndexOutOfBoundsException");
    } catch (IndexOutOfBoundsException e) {
      assertEquals(e.getMessage(),  "Index: 1, Size: 0");
    }
  }

  
  Here we can see that the tests relates to a get() method from the List interface. So for now, we only test one specific usage of a standard Java collection. As we try to get second element (indexed from 0) from an empty ArrayList  this will get us an IndexOutOfBoundsException. At least we expect it to act this way because line with the fail assertion is always assumed not to be reached.
  Moreover we use the asserEquals  checks if the error is as expected.
  
  
• Expected exception:
  
  

  @Test(expected = IndexOutOfBoundsException.class)
    public void testIndexOutOfBoundsException() {
      List list =  new ArrayList();
      list.get(1);
  }

  
  
  Here the example is similar but the annotation is informative enough to tell that the IndexOutOfBoundsException test method will fail if test is not going to be rised during the method call.
  
  
• Expected time of execution
  
  

  @Test(timeout = 1000L)
  public void searchPersonByName(){
    Person person = dao.search("John");
    assertEquals(person.getName(), "John");
  }

  
  This annotation states that the test is going to fail if the method execution will last longer that 1000 ms. As we can see the dao object is probably going take some time to access the data store, so we assure that any drawbacks e.g. with connection will not slow down the testing procedure longer than 1000 ms. Moreover, we check if the return value is actually "John".
  
  
• Parametrized:
  
  

  @RunWith(Parameterized.class)
   public class FibonacciTest {
          private int fInput;
          private int fExpected;
   
          public FibonacciTest(int input, int expected) {
                  fInput= input;
                  fExpected= expected;
          }
  
          @Parameters
          public static Collection<Object[]> data() {
                  return Arrays.asList(new Object[][] {
                                  Fibonacci,
                                  { { 0, 0 }, { 1, 1 }, { 2, 1 }, { 3, 2 }, { 4, 3 }, { 5, 5 },
                                                  { 6, 8 } } });
          }
   
          @Test
          public void test(@HeresHowYouGetValue Type value) {
                  assertAnswerKey(new Object[][] {
                                  Fibonacci,
                                  { { 0, 0 }, { 1, 1 }, { 2, 1 }, { 3, 2 }, { 4, 3 }, { 5, 5 },
                                                  { 6, 8 } } });
                  assertEquals(fExpected, Fibonacci.compute(fInput));
          }
   }

  
  Here we have a parameterized test example that allows developer to run the same test over and over again using different values. In this test we got  a public static method annotated with @Parameters that returns a Collection of Objects (as Array) as test data set. A public constructor can take in what is equivalent to one "row" of test data. The JUnit then asserEquals if the @Parameters values passed to an object and processed with the compute method are the same as  the expected value.
  
  
• Expected time of execution:
  
  

  public static class HasExpectedException {
          @Rule // test would work same without this rule
          public ExpectedException thrown= ExpectedException.none();
   
          @Test
          public void throwsNothing() {
      			// we don't expect exception and there is none, so: PASS.
          }
   
          @Test
          public void throwsNullPointerException() {
                  thrown.expect(NullPointerException.class);
                  throw new NullPointerException();
          }
   
          @Test
          public void throwsNullPointerExceptionWithMessage() {
                  thrown.expect(NullPointerException.class);
                  thrown.expectMessage("has happened?");
                  thrown.expectMessage(startsWith("what"));
  
                  throw new NullPointerException("what has happened?");
          }
   }

  
  Here all tests will pass. In this case we define a test behavior based on what exception is going to be thrown in each method and match the @Rule. In each method first we setup the expected exception then the expected exception is thrown. Therefore all tests pass. Additionally in last test method we also check if the thrown exception's message consists of a specific string. 

From Asotiation to Composition & More.

Association, Aggregation, Composition, Inheritance - what are those?

(OOP, UML)

Either association and aggregation  topic terms are both concepts of software design. They are considered in terms of relation between two classifiers, such as classes (but also use cases), that describe the relation reasons and rules  that governs it.
In this article we assume readers basic knowledge of UML class diagrams.

A relationship is a general term covering the specific types of logical connections found on class and object diagrams in UML.

Below we will try to focus on gathering information about a relationship between classes of objects:

Inheritance > Composition > Aggregation > Association > Link

Link

The most general relationship is Link. It simply only gives a notion of a relation not describing its particular properties. A link is a relationship between objects or instances of the classifiers. In general Link is an instance of an association, while an association is a relationship between two classifiers.

  

Association: uses a

Ex:a Class Man uses a Class Pen

It is the weakest of all relations. An association represents a structural relationship that connects two classifiers. Like attributes, associations record the properties of classifiers.

For example, in relationships between classes, you can use associations to show the design decisions that you made about classes in your application that contain data, and to show which of those classes need to share data. You can use an association's navigability feature, to show how an object of one class gains access to an object of another class or, in a reflexive association, to an object of the same class.    The name of an association describes the nature of the relationship between two classifiers and should be a verb or phrase. In the diagram editor, an association appears as a solid line between two classifiers.

In General:

• temporal relation between objects
• objects associated are independent (deleting one does not mean delete second)
• associated objects contain reference to the other object
• In Java equal to field

Example:

Passenger knows about his ticket reservations and reservation knows about who is its owner. In case reservation does not have reference to passenger when the association is unidirectional type (with an arrow in UML). With bidirectional association there are no arrows and both objects have references to each other

• In Java

The association relationship is a way of describing that a class knows about and holds a reference to another class. This can be described as a "has-a" relationship because the typical implementation in Java is through the use of an instance field. The relationship can be bi-directional with each class holding a reference to the other. Below there is a bi-directional association implemented many-to-one in Java using fields:

public class Department {

private Set staff = new HashSet();
...
}

public class Employee {

private Department department;
...
}

To make it uni-directional, one of the classes would not have its relation field.

What is the problem with a bi-directional association?

Unlike a relation in a RDBMS, a bi-directional association is stored on two ends. Lets illustrate it with example. We want to add a new employee to a department:

Department sales     = DepartmentsStore.getDepartment(...);
Department it        = DepartmentsStore.getDepartment(...);

Employee john = Employees.getEmployee(“john_id”);

john.getDepartment(); //  Lets say JOHN works in “IT” dept.

john.setDepartment(sales); //!? 

This would not work. We would still had to add “john” to “sales” and remove him from “it”:

sales.getStaff().add(john);
it.getStaff().remove(john);

So we have to take care of all this maintenance. Otherwise the application would collapse. And you can imagine in how many places this would have to be repeated in enterprise application.

Lets make it more OOP in terms of behaviour and responsibilities. We would have to consider business logic. Thats why we assume that the hire/fire is responsibility of Department.

public void hire(Employee employee)throws HumanResourceException {
staff.add(employee);
}

public void fire(Employee employee) throws HumanResourceException {

if (!staff.contains(employee)) throw new HumanResourceException("Employee does not work at this department");

staff.remove(employee);

}

But this is only the Department part not the Employee state needs to be modified:

void _changeDepartment(Departmentdepartment) {
    assert this.department == null;

    this.department = department;
}

void _removeFromItsDepartment() {
    assert this.department != null;
    this.department = null;

}

But still those methods should be used only by Department and there is no way to limit the scope of a method to one other class. You can only put it to the same package and follow convention of underscore meaning “used internally”.

This is still ugly and do it at home or work by yourself.

Aggregation: has a

Ex:a Class Man has a Class Car ( Car is still there when Man die )

Aggregation (white diamond) has no semantics beyond that of a regular association. It is, as Jim Rumbaugh puts it, a modeling placebo. People can, and do, use it - but there are no standard meanings for it. So if you see it, you should inquire as to what the author means by it. I would advise not using it yourself without some form of explanation.       

- Martin Fowler

This relationship is described as a “has-a” or “whole/part” relation between two classes. It is more strict relation than association. One of the classes - so called aggregate class - contains reference to the second class and is therefore said to have ownership of that second class. The class that is being referenced from within aggregate class is considered to be part-of the aggregate class. Aggregation is a stronger case of association as a directional association between objects.
You can say that you have aggregation between two objects when an object “has-a” another object. The additional information about relation’s direction is determined by deciding which object contains the other object.

In General:

• Stronger than association
• there is an owner and owned connected with their time of existence
• It is part-to-whole type of relation i.e. a part might belong to many unities therefore unity do not govern time of “part” existence
• aggregation means enclosing

Example:

• The university division does NOT create nor delete instance of professor it only contains it.
• Book register at library and particular book card. The register encloses book cards.
  
  
  
  

Composition: contains/owns a (Total composition) HAS-A

Ex:a Class Man owns a Class Heart ( When Man die, Heart die )

Composition (black diamond) does carry semantics. The most particular is that an object can only be the part of one composition relationship. So even if both windows and panels can hold menu-bars, any instance of menu-bar must be only held by one whole. This isn't a constraint that you can easily express with the regular multiplicity markers.   

- Martin Fowler

The strongest from the relationships. Composition is a special case of aggregation. A restricted aggregation is called composition. Therefore, composition is when a an object contains the other object and the contained object cannot exist without the existence of container object. In ther words: composition ensure that the containing object is responsible for the lifetime of the object it holds. If Object BAR is contained within Object FOO, then Object FOO is responsible for the creation and destruction of Object BAR. Unlike aggregation, Object BAR cannot exist without Object FOO.

In General:

• Just like aggregation relationship of part-whole
• The Whole object is the only owner, creator and administrator of the Part object.
• Part and Whole cannot exist without each other ie. their time of existence is connected
• deleting the Whole object removes all its Part objects
• Referred as “has-a”

Example:

• Encyklopedia has many toms.
• University has a Department
  

REMEMBER:

Both Composition and Aggregation are Associations.
Composition IS-A strong Association.
Aggregation IS-A weak Association.

Inheritance/Generalization: IS-A

Ex:a Class Man is a Class Human ( Man is a Human )

As the name inheritance suggests an object is able to inherit characteristics from another object. In more concrete terms, an object is able to pass on its state and behaviors to its children. For inheritance to work the objects need to have characteristics in common with each other. Inheritance can be defined as the process where one object acquires the properties of another. With the use of inheritance the information is made manageable in a hierarchical order. When we talk about inheritance, the most commonly used keyword would be extends and implements. These words would determine whether one object IS-A type of another. By using these keywords we can make one object acquire the properties of another object.

• Java

There is a quite complex explanation of how to consider inheritance in java at Java1 and Java2

General Example 1:

And the code:

public abstract class Item {

        int positionInList;
        String fullName;
}

public class MenuItem extends Item{

        Currency price;
        String description;

void changePrice (Currency newPrice){
             this.price = newPrice;
      }
}


/* AGGREGATION
* In Menu we can change MenuItem price, but the mItem is not only internal consern of Menu.
* It can be swapped, or even completely removed.
*/

public final class Menu {

      private List<MenuItem> mItem;


void addMenuItem(MenuItem mi){
            mItem.add(mi);
}

void changePrice(Currency newPrice, int position){

    if (mItem.get(position) != null){
      mItem..get(position).changePrice(newPrice);
    }
 }
}

public class Order {

private final List<OrderItem> oItems;

Order(List<OrderItem> items){
   this.oItems = new ArrayList<OrderItem>();
   this.oItems.addAll(items);
}

void modifyItem(String wish, int position){
    oIitems.get(pos).addNote(wish);
  }
}

public final class OrderItem extends Item{

String guestNotes;
List<int> positionInMenu;

private final addNote(String wish){
   this.guestNotes = wish;
}
}

General Example 2:

And the code:

public class University {

private List<Department> departments;

public void destroy(){
//it's composition, when i destroy a university I also destroy the departments. they cant live outside my university instance
    if(departments!=null)
    for(Department d : departments)
       d.destroy();
    departments.clean();
    departments = null;
  }
}

public class Department {

private List<Professor> professors;
private University university;

Department(University univ){
    this.university = univ;
}

public void destroy(){
//It's aggregation here, we just tell the professor they are fired but they can still keep living
   for(Professor p:professors)
     p.fire(this);
   professors.clean();
   professors = null;
   }
}

public class Professor extends Person{

private String fullTitle;
private List<Department> attachedDepartments;

public void destroy(){
}

public void fire(Department d){
    attachedDepartments.remove(d);
    }
}


public class Student extends Person{
}

public abstract class Person{
  
   String name;
   String surname;
}

There is more explanation of differences between inheritance and composition in following article.