Posts Tagged ‘dependecy management’

Build Automation Series: Part 3 – Automated Testing

March 29, 2009

In the last post in this series we added dependency management to our build process.

In this post we add automated testing to our build.

Automated Testing

Previously we have already added JUnit 4.5 as a dependency. To support mocking/stubbing in testing we also add Mockito 1.7 to our ivy.xml file.

We update our build.xml file to have a test target that will execute all JUnit tests (using junit ank task) and generate a html report (using junitreport ant task) at the end. If any of the tests fail the build fails.

Qualities of a Good Build

So far we are saying that a good build is:

  1. Automated
    1. IDE Agnostic – build is performed by some build tool (like ant) and is not tied to any specific IDE (like Eclipse or intelliJ)
    2. Executable tests are run as part of the build.
  2. Repeatable
    1. Is capable of being build on different machines from source checked out from source control.
    2. Clean – this target returns the state of the project to what it was when checked out from source control
    3. Compile – this target is responsible for compiling all source code of the project in a consistent way.
    4. Executable tests are run in a repeatable manner with the same result achievable after each build.
  3. Flexible
    1. Dependencies are easily managed (easy to upgrade to newer version of dependency if need be)

Coming up

In the next post, we will add a build target responsible for building the project and creating a deliverable.

View the code

You can browse the code for this post online at http://code.google.com/p/build-automation-environment/source/browse/#svn/branches/build-automation-series-3.

The code can be checked out from svn following the instructions here http://code.google.com/p/build-automation-environment/source/checkout.

Build Automation Series: Part 2 – Dependencies

March 28, 2009

In the last post in this series we created a simple build for our java project that cleaned and compiled the source code.

Next we want to be able to write automated tests using some java test automation framework. For now we will choose to go with Junit. To use Junit we would need to add the JUnit jar file as a dependency on our project. In the past I would of just simply downloaded the Junit jar myself and placed it within a lib folder of the java project and checked it in along with the rest of the source code for the project. A better approach however is to use a dependency management tool like Ivy.

Dependency Management: Ivy

To use ivy we:

  1. Download ivy (version 2.0)
  2. Create an ivy.xml file for the project
  3. Add ant tasks to our build.xml file

In our ivy.xml file we add our dependencies. By default ivy will look up a maven2 repository for the dependencies you add. If you goto http://www.mvnrepository.com and search for ‘junit’ (lowercase) you will see it find a list of results related to junit. Click on the junit >> junit link you will see it display all the binaries for junit that exist on the repository. Also on the page is the POM Dependency xml:

<dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <version>4.5</version>
</dependency>

We use the POM Dependency information on ivy as the following:

<dependencies>
	<dependency org="[groupId]" name="[artifactId]" rev="[version]" />
</dependencies>

so our junit dependency looks like:

<dependencies>
	<dependency org="junit" name="junit" rev="4.5" />
</dependencies>

Dependency Management in the Build: Ant + Ivy

To retrieve the projects dependencies, we need to call ivy:retrieve. The first time we try to retrieve the dependencies ivy will try to download these dependencies over HTTP. These are placed in the lib folder of our project and they are also cached in a local ivy cache. So if we try to retrieve these dependencies again ivy will goto the cache and get rather than going over HTTP.

So we also add a target to our build that allows us to clean the cache if we need to. See the build.xml file with added.

Command line usage

One of the key qualities of our build is that it is IDE agnostic. Ant is our build tool and we need to be able to perform a build using ant only from the command line. To do this the following should be in place:

  1. Download Ant (version 1.7.1)
  2. Set ANT_HOME to location where apache ant was downloaded
  3. Add ANT_HOMEbin to your PATH

Should be able to execute ant -version from anywhere and see it report what version of Ant is installed.

To allow Ivy’s ant tasks to be used within your ant build file from the command line, we add the following xml to our build.xml.

<!-- set path so ivy will be picked up when using ant from the command line -->
<path id="ivy.lib.path">
   <fileset dir="../build-automation-environment/lib" includes="*.jar" />
</path>
<taskdef resource="org/apache/ivy/ant/antlib.xml"
           uri="antlib:org.apache.ivy.ant" classpathref="ivy.lib.path" />

Eclipse integration

Integration of the build with an IDE can be helpful at times. To integration ivy with eclipse, we add the download version of ivy jar to Windowns->Preferences->Ant->Runtime->Global Entries.

I have also created eclipse launchers that execute a specified target(s) on the build.xml file. These are located in the eclipse-ant folder and can be invoked from the top menu as shown below:

eclipse-launchers

Qualities of a Good Build

So far we are saying that a good build is:

  1. Automated
    1. IDE Agnostic – build is performed by some build tool (like ant) and is not tied to any specific IDE (like Eclipse or intelliJ)
  2. Repeatable
    1. Is capable of being build on different machines from source checked out from source control.
    2. Clean – this target returns the state of the project to what it was when checked out from source control
    3. Compile – this target is responsible for compiling all source code of the project in a consistent way.
  3. Flexible
    1. Dependencies are easily managed (easy to upgrade to newer version of dependency if need be)

Coming up

In the next post, we will add a few tests and add automated testing to our build

View the code

You can browse the code for this post online at http://code.google.com/p/build-automation-environment/source/browse/#svn/branches/build-automation-series-2.

The code can be checked out from svn following the instructions here http://code.google.com/p/build-automation-environment/source/checkout.

Build Automation Series: Part 1 – Automated and Repeatable

March 25, 2009

As part of this series I am going to look at creating an automated build for java projects using the various technologies out there. All code examples will be checked into source control on google code at http://code.google.com/p/build-automation-environment/.

What makes a good build?

A goog build is automated and repeatable

A build should be automated to remove any possibility of human error during the build process. It should also be repeatable as we need to be sure that we will get the same results.

To start we will use a apache’s ant build tool to build our simple Java project.

Simple Java Project Structure

We have a simple java project checked out with the following structure:

simple-java-project-structure

we create the following ant build.xml file that allows us to clean and compile any source or test code.

The above build file allows to to compile our java source and test files in an automated and repeatable way. The clean target will consistently return the project back to the state that is identical to what it was before the build.

Qualities of a Good Build

So far we are saying that a good build is:

  1. Automated and Repeatable
    1. IDE Agnostic – build is performed by some build tool (like ant) and is not tied to any specific IDE (like Eclipse or intelliJ)
    2. Clean – this target returns the state of the project to what it was when checked out from source control
    3. Compile – this target is responsible for compiling all source code of the project in a consistent way.

Coming up:

One of the basic things we need to do when developing is to create Java test’s as well as Java source. To do this we typically will use some thrid party dependencies to aid this such as Junit, TestNG, Mockito, JMock, EasyMock etc

We will look into handling this using a dependency manager like Ivy in the next part of the series.

View the code

You can browse the code for this post online at http://code.google.com/p/build-automation-environment/source/browse/#svn/branches/build-automation-series-1.

The code can be checked out from svn following the instructions here http://code.google.com/p/build-automation-environment/source/checkout.