Archive

Archive for the ‘Java’ Category

Continuous Enterprise Development in Java by Andrew Lee Rubinger, Aslak Knutsen

May 14th, 2015

continuous_enterprise_development_java_cover
What is Continuous Enterprise Development?
The term Enterprise is used for the category of business software that are complex, scalable, distributed, component-based, and mission-critical.
Continuous software development is an umbrella term that describes several aspects of iterative software application development, including continuous integration, continuous delivery, continuous testing and continuous deployment – definition from http://searchsoftwarequality.techtarget.com/definition/Continuous-Software-Development.

  • Continuous integration refers specifically to the process of steadily adding new code commits to source code, a concept that has evolved over the years. Originally, a daily build was the standard for continuous integration. Today, the usual rule is for each team member to submit work as soon as it is finished and for a build to be conducted with each significant change. Usually, a certain baseline of automated unit and integration testing is performed to ensure that new code does not break the build. This way developers know as soon as they’re done if their code will meet minimum standards and they can fix problems while the code is still fresh in their minds. An important advantage of continuous integration is that it provides developers with immediate feedback and status updates for the software they are working on.
  • Continuous delivery builds on continuous integration and as with continuous integration, each code commit is automatically tested at the time it is added. In addition to the automated unit and integration testing, a continuous delivery system will include functional tests, regression tests and possibly other tests, such as pre-generated acceptance tests. After passing the automated tests, the code changes are sent to a staging environment for deployment.
  • Continuous testing adds manual testing to the continuous delivery model. With continuous testing, the test group will constantly test the most up-to-date version of available code. Continuous testing generally adds manual exploratory tests and user acceptance testing. This approach to testing is different from traditional testing because the software under test is expected to change over time, independent of a defined test-release schedule.
  • Continuous deployment adds more automation to the process to the software development process. After passing all the automated delivery tests, each code commit is deployed into production as soon as it is available. Because changes are delivered to end-users quickly and without human intervention, continuous deployment can be seen as risky. It requires a high degree of confidence both in the existing application infrastructure and in the development team. Continuous deployment is frequently seen in consumer-facing Web and mobile applications that frequently push updates to their customers as a part of the value that they bring.

The Authors
Andrew Lee Rubinger is an advocate for and speaker on open, testable enterprise Java development, member of the JBoss Core Development Team and Technical Lead of the ShrinkWrap project.
Aslak Knutsen is the project lead of Arquillian, is a Senior SoftwareEngineer at JBoss, by Red Hat. He’s involved in projects such as Arquillian, ShrinkWrap, Weld and Seam 3, and one of the founders of the JBoss Testing initiative.

About The Book
The are various tools explained and used as example for continuous development and testing in this book. Other than JBoss products such as JBoss Forge, JBoss EAP, other important tools such as Maven, Git, Arquillian, ShrinkWrap, OpenShift, Selenium, QUnit and AngularJS are used for the example project.
The book introduces its readers to the importance of proactive error handling and software quality that is the practice in recent software development.
It introduces JUnit and TestNG as test frameworks among the suggested tools as a test plaform for Java EE applications.
The book came along with a great example web application – GeekSeek that is publicly available at http://geekseek.continuousdev.org.
Chapters 5,6, and 7 provides some examples about testing the persistence and business layer while chapter 8 has some good information about REST services. It is crucial to know the stages of REST maturity level used in application, as most developers would misunderstood that their applications are RESTful just because the application is making calls with HTTP methods to some resource URIs.
The book then moved on to making the example application testable on the UI layer and guide readers to have the web app deployed automatically via Jenkins to Openshift.

Chapters
1. Continuity
2. Enabling Technologies
3. Scratch to Production
4. Requirements and the Example Application
5. Java Persistence and Relational Model
6. NoSQL : Data Grids and Graph Databases
7. Business Logic and the Services Layer
8. REST and Adressable Services
9. Security
10. The User Interface
11. Assembly and Deployment
12. Epilogue

Conclusion
This book is very important for modern day web and enterprise application developers to learn to make their application testable at all stages of development. The target reader of this book are experience developers and the examples and content are great to be used as a deployable project right away.
The content of this book can be sampled here, or access online at GitHub or purhased from Amazon via the following link:

Books, Java, Open Source, Review , , ,

Running JUnit tests in Maven with Surefire Plugin and skipTests in default packaging

March 3rd, 2015

Further to the JUnit test we have created, it’s time to have it built into a maven build script so that the test can be run.
Once you have JUnit in your pom.xml file, maven will run tests with JUnit and all valid JUnit test classes under src/test/java directory.
However if you are using more than one test framework such as both TestNG and JUnit, you will need to explicitly specify JUnit as the test provider.

<plugins>
[...]
  <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>2.18.1</version>
    <dependencies>
      <dependency>
        <groupId>org.apache.maven.surefire</groupId>
        <artifactId>surefire-junit47</artifactId>
        <version>2.18.1</version>
      </dependency>
    </dependencies>
  </plugin>
[...]
</plugins>

For the default maven packaging, you might not want to run test and the tests can be run as a separate job/task.
To address this, all you need to do is create a skipTests property in the pom.xml and have it set to false only when you need to run the tests.


    <properties> 
    	<skipTests>true</skipTests> 
    </properties>

Use skipTests in the configuration element.


<plugins>
[...]
  <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>2.18.1</version>
    <dependencies>
      <dependency>
        <groupId>org.apache.maven.surefire</groupId>
        <artifactId>surefire-junit47</artifactId>
        <version>2.18.1</version>
      </dependency>
    </dependencies>
    <configuration>
      <skipTests>${skipTests}</skipTests>
    </configuration>
  </plugin>
[...]
</plugins>

To run the tests:
mvn test -DskipTests=false

Java, Software , ,

Quick Guide to JUnit multiple parameter tests with Parameterized annotation

February 15th, 2015

It is extremely easy to create JUnit test classes to run and test your application or Java code.
JUnit is a simple framework to write repeatable tests. It is an instance of the xUnit architecture for unit testing frameworks.
All it needs is to include the JUnit library and use the @Test annotation for the method you need to run as test.
However, sometimes we need the convenience of the same test method to run with different parameters.
Following is an example how it can be done easily with some changes to a single test method by adding @RunWith(Parameterized.class) before the class name and then initialize a collection of parameters with @Parameters.
You can also read the parameters from a data provider once using a initializing method with @BeforeClass.

package net.marvinlee.test;
 
import java.util.ArrayList;
import java.util.Collection;
import org.junit.Assert;
import org.junit.BeforeClass;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.junit.runners.Parameterized;
import org.junit.runners.Parameterized.Parameters;
 

@RunWith(Parameterized.class)
public class JunitTest
{

	private String code;
	private String description;
	

	public JunitTest(String code, String description)
	{
		super();
		this.code = code;
		this.description = description;
	}

	 @Parameters
	 public static Collection getParameters() 
	 { 
		 ArrayList<Object[]> paramList = new ArrayList<Object[]>();
		 addTestcases(paramList);
		 return paramList;
	 }

	protected static void addTestcases(ArrayList<Object[]> paramList)
	{
		for(int i=1;i<=10;i++)
		{
			paramList.add(new Object[]{"Code" + i, "Description " + i});
		}
	}

	@BeforeClass
	public static void init() 
	{ 
		System.out.println("Current dir:" +  JunitTest.class.getClassLoader().getResource("").getPath()); 
	}
	 

	@Test
	public void validateCases() 
	{
		boolean matched = ((code.equals("Code5") && description.equals("Description 5"))
			|| (code.equals("Code6") && description.equals("Description 6")));
		Assert.assertTrue("Failed test=" + code, matched);
		 
	}
	 
}

JUnit test classes can be run with Eclipse IDE and the above test class will show run results similar to the following screenshot.
Only the 4th and 5th testcases that match with the hardcoded values will pass while we get remaining 8 failures.
junit

Have a run with it!

Java, Software ,