
At work, recently I did a code cleanup of an existing Java project. After that exercise, I could see a common set of code violations that occur again and again in the code. So, I came up with a list of such common violations and shared it with my peers so that an awareness would help to improve the code quality and maintainability. I'm sharing the list here to a bigger audience.

The list is not in any particular order and all derived from the rules enforced by code quality tools such as [CheckStyle][1], [FindBugs][2] and [PMD][3].

[1]: http://checkstyle.sourceforge.net/ "Checkstyle is a development tool to help programmers write Java code that adheres to a coding standard"
[2]: http://findbugs.sourceforge.net/ "Find bugs in java program"
[3]: http://pmd.sourceforge.net/ " source code analyzer"

Here we go!

## Format source code and Organize imports in Eclipse:

Eclipse provides the option to auto-format the source code and organize the imports (thereby removing unused ones). You can use the following shortcut keys to invoke these functions.

- **Ctrl Shift F** - Formats the source code.
- **Ctrl Shift O** - Organizes the imports and removes the unused ones.

Instead of you manually invoking these two functions, you can tell Eclipse to auto-format and auto-organize whenever you save a file. To do this, in Eclipse, go to **Window -> Preferences -> Java -> Editor -> Save Actions** and then enable **Perform the selected actions on save** and check **Format source code** **Organize imports**.

## Avoid multiple returns (exit points) in methods:

In your methods, make sure that you have only **one exit point**. Do not use returns in more than one places in a method body.

For example, the below code is **NOT RECOMMENDED** because it has more then one exit points (return statements).

```java
    private boolean isEligible(int age){
      if(age > 18){
        return true;
      }else{
        return false;
      }
    }
```

The above code can be rewritten like this (of course, the below code can be still improved, but that'll be later).

```java
    private boolean isEligible(int age){
      boolean result;
      if(age > 18){
        result = true;
      }else{
        result = false;
      }
      return result;
    }
```

## Simplify if-else methods:

We write several utility methods that takes a parameter, checks for some conditions and returns a value based on the condition. For example, consider the **isEligible** method that you just saw in the previous point.

```java
    private boolean isEligible(int age){
      boolean result;
      if(age > 18){
        result = true;
      }else{
        result = false;
      }
      return result;
    }
```

The entire method can be re-written as a **single return** statement as below.

```java
    private boolean isEligible(int age){
      return age > 18;
    }
```

## Do not create new instances of Boolean, Integer or String:

Avoid creating new instances of Boolean, Integer, String etc. For example, instead of using `new Boolean(true)`, use `Boolean.valueOf(true)`. The later statement has the same effect of the former one, but it has improved performance.

## Use curly braces around block statements.

Never forget to use curly braces around block level statements such as _if_, _for_, _while_. This reduces the ambiguity of your code and avoids the chances of introducing a new bug when you modify the block level statement.

**NOT RECOMMENDED**

```java
    if(age > 18)
      result = true;
    else
      result = false;
```

**RECOMMENDED**

```java
    if(age > 18){
      result = true;
    }else{
      result = false;
    }
```

## Mark method parameters as final, wherever applicable:

Always mark the method parameters as _final_ wherever applicable. If you do so, when you accidentally modify the value of the parameter, you'll get a compiler warning. Also, it makes the compiler to optimize the byte code in a better way.

**RECOMMENDED**

```java
    private boolean isEligible(final int age){ ... }
```

## Name _public static final_ fields in UPPERCASE:

Always name the _public static final_ fields (also known as _Constants_) in UPPERCASE. This lets you to easily differentiate constant fields from the local variables.

**NOT RECOMMENDED**

```java
public static final String testAccountNo = "12345678";
```

**RECOMMENDED**

```java
public static final String TEST_ACCOUNT_NO = "12345678";
```

## Combine multiple _if_ statements into one:

Wherever possible, try to combine multiple _if_ statements into single one.

For example, the below code;

```java
    if(age > 18){
      if( voted == false){
        // eligible to vote.
      }
    }
```

can be combined into single _if_ statements, as:

```java
    if(age > 18 && !voted){
      // eligible to vote
    }
```

## _switch_ should have _default_:

Always add a _default_ case for the _switch_ statements.

## Avoid duplicate string literals, instead create a constant:

If you have to use a string in several places, avoid using it as a literal. Instead create a String constant and use it.

For example, from the below code,

```java
    private void someMethod(){
      logger.log("My Application"   e);
      ....
      ....
      logger.log("My Application"   f);
    }
```

The string literal 'My Application' can be made as an Constant and used in the code.

```java
    public static final String MY_APP = "My Application";

    private void someMethod(){
      logger.log(MY_APP   e);
      ....
      ....
      logger.log(MY_APP   f);
    }
```

## Additional Resources:

- A collection of [Java best practices][4].
- List of available [Checkstyle checks][5].
- List of [PMD Rule sets][6]

[4]: http://www.javapractices.com/home/HomeAction.do
[5]: http://checkstyle.sourceforge.net/availablechecks.html
[6]: http://pmd.sourceforge.net/rules/index.html


Common code violations in Java


In this post, I'm going to show you what EasyMock is and how you can use it for testing your java application. For this purpose, I'm going to create a **simple Portfolio **application and test it using **JUnit & EasyMock** libraries.

Before we begin, lets first understand the need behind using EasyMock. Lets say, you are building an Android mobile application for maintaining user's stock portfolios. Your application would use a stock market service to retrieve stock prices from a real server (such as NASDAQ).

When it comes to testing your code, you wouldn't want to hit the real stock market server for fetching the stock prices. Instead, you would like some dummy price values. So, you need to mock the stock market service that returns dummy values without hitting the real server.

**EasyMock** is exactly doing the same - helps you to mock interfaces. You can pre-define the behavior of your mock objects and then use this mock object in your code for testing. Because, you are only concerned about testing **your logic** and not the external services or objects. So, it makes sense mock the external services.

To make it clear, have a look at the below code excerpt (we'll see the complete code in a while):

```java
StockMarket marketMock = EasyMock.createMock(StockMarket.class);
EasyMock.expect(marketMock.getPrice("EBAY")).andReturn(42.00);
EasyMock.replay(marketMock);
```

In the first line, we ask the EasyMock to create a mock object for our StockMarket interface. And then in the second line, we define how this mock object should behave - i.e., when the *getPrice()* method is called with the parameter *'EBAY'*, the mock should return *42.00*. And then, we call the *replay()* method, to make the mock object ready to use.

So, that pretty much set the context about the EasyMock and it's usage. Let's dive into our **Portfolio **application.

You can download the complete source code [from Github][1].

## Portfolio application

 [1]: https://github.com/vraa/SimplePortfolio "Simple portfolio source code in GitHub"

Our Portfolio application is really simple. It has a **Stock **class to represent a stock name and quantity and the **Portfolio **class to hold a list of stocks. This Portfolio class has a method to calculate the total value of the portfolio. Our class uses a **StockMarket **(an interface) object to retrieve the stock prices. While testing our code, we will mock this **StockMarket **using EasyMock.

### Stock.java

A very simple Plain Old Java Object (POJO) to represent a single stock.

```java
package com.veerasundar.easymock;

public class Stock {

  private String name;
  private int quantity;

  public Stock(String name, int quantity) {
    this.name = name;
    this.quantity = quantity;
  }

  public String getName() {
    return name;
  }

  public void setName(String name) {
    this.name = name;
  }

  public int getQuantity() {
    return quantity;
  }

  public void setQuantity(int quantity) {
    this.quantity = quantity;
  }

}
```

### StockMarket.java

An interface to represent a stock market service. It has a method that returns the stock price of the given stock name.

```java
package com.veerasundar.easymock;

public interface StockMarket {
  public Double getPrice(String stockName);
}
```

### Portfolio.java

This object holds a list of **Stock **objects and a method to calculate the total value of the portfolio. It uses a **StockMarket **object to retrieve the stock prices. Since it is not a good practice to hard code the dependencies, we haven't initialized the **stockMarket **object. We'll inject it later using our test code.

```java
package com.veerasundar.easymock;

import java.util.ArrayList;
import java.util.List;

public class Portfolio {

  private String name;
  private StockMarket stockMarket;

  private List<Stock> stocks = new ArrayList<Stock>();

  /*
   * this method gets the market value for each stock, sums it up and returns
   * the total value of the portfolio.
   */
  public Double getTotalValue() {
    Double value = 0.0;
    for (Stock stock : this.stocks) {
      value += (stockMarket.getPrice(stock.getName()) * stock
          .getQuantity());
    }
    return value;
  }

  public String getName() {
    return name;
  }

  public void setName(String name) {
    this.name = name;
  }

  public List<Stock> getStocks() {
    return stocks;
  }

  public void setStocks(List<Stock> stocks) {
    this.stocks = stocks;
  }

  public void addStock(Stock stock) {
    stocks.add(stock);
  }

  public StockMarket getStockMarket() {
    return stockMarket;
  }

  public void setStockMarket(StockMarket stockMarket) {
    this.stockMarket = stockMarket;
  }
}
```

So, now we have coded the entire application. In this, we are going to test the **Portfolio.getTotalValue() **method, because that's where our business logic is.

## Testing Portfolio application using JUnit and EasyMock

If you haven't used JUnit before, then it is a good time to [Get started with JUnit][2].

### PortfolioTest.java

 [2]: https://veerasundar.com/blog/getting-started-with-junit-4-java-testing-framework "Getting started with JUnit 4"

```java
package com.veerasundar.easymock.tests;

import junit.framework.TestCase;

import org.easymock.EasyMock;
import org.junit.Before;
import org.junit.Test;

import com.veerasundar.easymock.Portfolio;
import com.veerasundar.easymock.Stock;
import com.veerasundar.easymock.StockMarket;

public class PortfolioTest extends TestCase {

  private Portfolio portfolio;
  private StockMarket marketMock;

  @Before
  public void setUp() {
    portfolio = new Portfolio();
    portfolio.setName("Veera's portfolio.");
    marketMock = EasyMock.createMock(StockMarket.class);
    portfolio.setStockMarket(marketMock);
  }

  @Test
  public void testGetTotalValue() {

    /* = Setup our mock object with the expected values */
    EasyMock.expect(marketMock.getPrice("EBAY")).andReturn(42.00);
    EasyMock.replay(marketMock);

    /* = Now start testing our portfolio */
    Stock ebayStock = new Stock("EBAY", 2);
    portfolio.addStock(ebayStock);
    assertEquals(84.00, portfolio.getTotalValue());
  }

}
```

As you can see, during **setUp()** we are creating new **Portfolio** object. Then we ask **EasyMock **to create a mock object for the **StockMarket** interface. Then we inject this mock object into our portfolio object using *portfolio.setStockMarket()* method.

In the **@Test** method, we define how our mock object should behave when called, using the below code:

```java
EasyMock.expect(marketMock.getPrice("EBAY")).andReturn(42.00);
EasyMock.replay(marketMock);
```

So, here after our mock object's **getPrice** method** **would return *42.00* when called with *EBAY*.

Then we are creating a **ebayStock** with 2 quantities and add that to our portfolio. Since we setup the stock price of EBAY as 42.00, we know that the total value of our portfolio is 84.00 (i.e. 2 x 42.00). In the last line, we are asserting the same using the JUnit **assertEquals()** method.

The above test should run successfully if we haven't made any mistakes in the **getTotalValue() **code. Otherwise, the test would fail.

## Conclusion

So, that's how we use the **EasyMock** library to mock the external services/objects and use them in our testing code. EasyMock can do much more than what I shown in this post. I'll probably try to cover some advanced usage scenarios in my next posts.
```


EasyMock tutorial - Getting Started


In my last post about [Getting Started with JUnit 4][1], I talked about the basic concepts of JUnit testing framework and how to write a test case using JUnit 4. In this post, I'll write about some tips and strategies for using JUnit effectively. We will start with JUnit annotation @Ignore.

[1]: https://veerasundar.com/blog/getting-started-with-junit-4-java-testing-framework "Getting started with JUnit 4 - In order to test the java applications effectivley, we can use JUnit. framework Junit is an open source, Java testing framework that helps us to write and run tests for our application. Using JUnit, we can setup your testing objects, write the test methods for our objects, run those test methods and assert the testing outcomes for expected results."

## Temporarily disabling a JUnit test:

In JUnit 4, it is possible to temperorily disable a test using the annotation **_@Ignore_**. This technique is very useful in scenarios where you are not done with that particular test case, but still want to run the other tests that are present in that test suite/class. The test methods which are annotated with both _@Test_ and _@Ignore_ will be ignored by the test runner. See the example below for a clear understanding.

```java
    @Test
    public void testSomeMethod(){
            System.out.println("T'll be called");
    }

    @Ignore
    @Test
    public void testSomeOtherMethod(){
            System.out.println("T'll be ignored");
    }
```

## Testing for a specific Exception in JUnit testing method:

Suppose you want to check for a specific exception thrown by your testing method, you can use the **_expected_** option of _@Test_ annotation. You can mention the Exception type that you expect the testing method to throw in the 'Ëœexpected' option. If the method throws the exception then test is considered as passed, otherwise the test will be considered as failed.

```java
    @Test(expected=IllegalArgumentException.class)
    public void testSomeMethod(){
       myObj.someMethod();
    }
```

## Testing for execution time of your method:

If you want to check if your testing method takes too long to execute, you can do that by mentioning your expected execution time using **_timeout_** option of @Test annotation. If your testing method takes longer than the time you mentioned, then the test will be considred as _failed._ The time is measured in _milliseconds._ Below is a code snippet for this.

```java
    @Test(timeout=2000)
    public void testSomeMethod(){
       myObj.someMethod();
    }
```

That's for now. I hope that the above tips will help you t write effective JUnit tests. Feel free to share any other tips on JUnit. I'll happy to hear from you.


JUnit 4 - testing for exception, execution time and disabling a test


One of the important skill that every Java developer must possess is the **application testing**. A developer may follow software standards, religiously use all the available design patterns or do hundreds of code reviews on his code, but testing is the one which confirms his code quality and reliability. This is proved by the growing popularity of **Test Driven Development (TDD)** methodology, where the developer write tests first and the build the application to pass those tests. The objective of this post is not to explain TDD or the bigger things. Instead I'll focus on the basic things first. This is a very basic introduction to JUnit, so if you already knew about JUnit, you can safely skip reading this blog post.

All of us, the java developers, would have used a well-proven testing method, when we started learning Java. It's called as the **'ËœSyso testing'**, which is nothing but _System.out.println()_ . We usually print the variable values in the console and check them manually to make sure that the function is doing what it has to do. For small projects, this approach is quick and useful. But, for the medium/big sized projects, using 'ËœSyso testing' isn't that effective. Even for small projects, using Syso testing will turn ineffective as the development continues.

In order to test the java applications effectivley, we can use **JUnit. framework** Junit is an open source, Java testing framework that helps us to write and run tests for our application. Using JUnit, we can setup your testing objects, write the test methods for our objects, run those test methods and assert the testing outcomes for expected results. Since running the test methods can be automated (either by using Ant/IDEs built-in JUnit support), considerable amount of time can be saved during the testing phase.

## Basic steps needed for writing a JUnit test case:

1.  First, we need to write the Java class (duh!). Let's say we have the below _PayrollCalculator_ java class, which I'm going to use as an example.  

```java
        package com.veerasundar.budgeter;
        public class PayrollCalculator {

        	public double calculate(double rate, int days) {
        		return rate * days;
        	}

        }
```

2.  Then, we need to create a new Test class with testing methods in it. We can create this test class in the same package as of _PayrollCalculator._ But for better organization, it is recommended to have the test classes in a different folders. So, create a new _source folder_ and put the below test class in it.  

```java
        package com.veerasundar.budgeter.junit;

        import static org.junit.Assert.assertEquals;

        import org.junit.Test;

        import com.veerasundar.budgeter.PayrollCalculator;

        public class PayrollTesCase {

        	@Test
        	public void testCalculate() {
        		PayrollCalculator payCalc = new PayrollCalculator();
        		assertEquals(300 * 30, payCalc.calculate(300, 30));

        		System.out.println("I'm the test method");
        	}

        }
```

3.  In Junit 4.x, all the testing methods are identified with **@Test** annotation.so, the method _testCalculate_ will be identified as test method and will be run by the Junit runner.
4.  If you are using an IDE such as Eclipse, the _PayrollTestCase_ class can be executed by right-clicking on the test class and selecting **Run as JUnit test case.** This will invoke the test environment methods, if any (explained later in this article) and then invoke all the methods that are annotated with @Test annotation. If the assert statement that we put inside those test methods are success, then JUnit will run successfully. Otherwise, the errors will be reported in the **JUnit view** in Eclipse window.

## Understanding how an JUnit test method is executed

When you run a JUnit test case, you can optionally specify some other methods also to be executed along with your test method. Bascially this _additional_ methods are used to setup your testing environment, for example getting a database connection, and for releasing the resources used during the testing such as closing the database connection. These methods are called as _fixtures_ and can be used to initialize the objects that are used by more than one test methods, thus reducing the amount of code.

In JUnit 4.x all the methods are annotated. So, the flow of control in JUnit methods can be described as below:

> @BeforeClass -> @Before -> @Test -> @After -> @AfterClass

You can annotate any method with the above-mentioned annotation. See the below coding example to know how these annotated methods are executed.

```java
    package com.veerasundar.budgeter.junit;

    import static org.junit.Assert.assertEquals;

    import org.junit.After;
    import org.junit.AfterClass;
    import org.junit.Before;
    import org.junit.BeforeClass;
    import org.junit.Test;

    import com.veerasundar.budgeter.PayrollCalculator;

    public class PayrollTesCase {

    	@BeforeClass
    	public static void runsBeforeTheTestSuite(){
    		System.out.println("I run before any test method is executed");
    	}


    	@Before
    	public void runOnceBeforeEachTestMethod(){
    		System.out.println("I run once before each test method is executed");
    	}


    	@Test
    	public void testCalculate() {
    		PayrollCalculator payCalc = new PayrollCalculator();
    		assertEquals(300 * 30, payCalc.calculate(300, 30));

    		System.out.println("I'm the test method");
    	}

    	@After
    	public void runOnceAfterEachTestMethod(){
    		System.out.println("I run once after each test method is executed");
    	}

    	@AfterClass
    	public static void runsAfterTheTestSuite(){
    		System.out.println("I run after all the test methods are executed");
    	}
    }
```

Also, please note that the methods annotated with @BeforeClass and @AfterClass should be _static methods_ since they will be called before any test method is executed.

I hope this post explains the basics of JUnit 4 clearly. In my next post, I'll be sharing some more tips on JUnit testing.


#test (4)