A while back I posted a movie on installing and configuring CruiseControl on Windows, so I figured I’d give a brief overview in Linux. I am using Ubuntu so some of the examples may be different for you — depending on the UNIX/Linux flavor you’re using. This assumes that Java is in your system’s path. To verify, type:
echo $JAVA_HOME -or-
echo $PATH
Step 1
Download CruiseControl to a temporary location.
Step 2
Extract it to the location you wish to install it. For example:
unzip cruisecontrol.zip /opt
Step 3
Create a user and group and ensure that CruiseControl files are owned by this group. For instance, as root, create a cimasters group and a cimaster user:
/usr/sbin/useradd -G cimasters cimaster
If /usr/sbin/ has been added to your path, you only need to enter useradd.
Now, change the owner of all CruiseControl files like this:
I noticed a slight quirk between IE and Firefox when testing with Selenium the other day, which in retrospect makes sense; however, it serves to demonstrate the challenges of user acceptance testing in the face of a heterogeneous browsing community.
Firefox manipulation of form selections works via the type command of the DefaultSelenium object. For example, the following sequence of commands works with Firefox:
driver.open(appPath + "/CreateUser.html");
driver.type("name", "SpongeBob");
driver.type("genus", "Sponge"); //this only works with firefox
driver.click("submit");
As you can see from the code above, genus is the name of a selection element on a web form.
IE, however, doesn’t accept the type command within form sections– you must actually use the select method of the DefaultSelenium object as follows:
The fix, luckily, is to go with the code that works for IE as it’ll also work within Firefox. It goes to show you, however, that writing generic code to facilitate testing of web code that’ll be viewed by multiple browser types can be challenging. If you write some tests that work for one browser, don’t assume they’ll work for them all until you’ve actually tried.
Do you have a long running build? Often times, the testing aspect of a build (i.e. executing a suite of JUnit tests) consumes the vast majority of time; however, code inspections have also been known to add quite a bit of time, especially when the code base is large. If you find that your inspections are long running, there’s a quick and easy way to speed things up: use Ant’s parallel task.
For example, imagine the following target takes enough time that warrants you either stop running it or figure out a way to make it execute faster:
As you can see, this target simply calls a series of inspection targets sequentially. With Ant’s parallel task, you can effectively force Ant to launch these targets in multiple threads. Just be sure that these targets don’t interact with each other– just like coding in threading, you’ll have to think through scenarios where using parallel is helpful and where it’s not.
I can take the target defined above and wrap the antcall invocations with parallel and boost performance. Of course, results will vary; however, for a particular project on which I applied this technique, I saw a measurable improvement in overall build time execution.
There are many culprits that contribute to prolonged builds; nevertheless, there are a number of techniques that can assuage long running targets, including running them in parallel. That certainly beats the “just don’t run them” alternative too!
The sixth installment of the popular “Automation for the people” series by Paul Duvall was recently published. The article provides an overview of the different types of developer tests along with examples that you can add to your build process and run continually using a Continuous Integration (CI) system.
Published by IBM developerWorks, the article covers the following:
The key to improving the reliability of your software is to run tests whenever a change occurs. Continuous testing leverages the practice of Continuous Integration to ensure highly reliable code.
There’s a new release of NUnit that contains some handy constraint based assertions– using these new Assert methods in combination with the newly defined Constraint objects have the ultimate benefit of making test cases easier to read. Plus, they’re more fun to code!
Automated build systems (like NAnt or Ant) are excellent mechanisms with which to incorporate quality gates. An obvious quality gate is a successful test run (i.e. did all developer tests pass?); however, with the incorporation of software inspectors, you can introduce additional quality gates that verify specific code metrics or even combinations of metrics. Some software inspectors, in fact, already have built in mechanisms to cause build failures if specific thresholds are exceed, like Cobertura, which has a cobertura-check task that checks specific coverage values.
If a particular tool doesn’t provide an automatic failure hook, you can easily build one– in fact, combining Groovy’s expressive scripting power with Ant makes this process quite easy. For example, you can audit a JavaNCSS (a software inspector that reports code size and complexity) report and fail a build if the maximum complexity (which is reported for individual methods) is exceeded.
Imagine that as an organization, your team has set a goal that no method will have a cyclomatic complexity greater than 15. If for some reason, a method’s ccn (cyclomatic complexity number) is found to exceed 15, then a quality gate is tripped and a build is failed. This process is actually quite easy to script via Groovy in an Ant task. A number of things need to be in place for this to work:
A threshold value needs to be defined, preferably via an Ant property
JavaNCSS needs to be run as a prerequisite as the threshold task will parse the resulting XML report
If the defined threshold value is exceeded, then Ant’s fail task will be invoked. Watch how easy this is with Groovy:
<property name="maxccn" value="15" />
<target name="threshold-check" depends="groovy-init,javancss">
<groovy classpathref="build.classpath">
def fullpath = "${properties.basedir}/${properties.defaulttargetdir}"
def jncssPath = "${fullpath}/javancss_metrics.xml"
def jdoc = new XmlSlurper().parse(jncssPath)
int maxccn = 0
if(jdoc != null){
jdoc.functions.function.each{ mthd ->
int ccn = Integer.parseInt(mthd.ccn.text())
if (ccn > maxccn){
maxccn = ccn
}
}
}
if(maxccn > Integer.parseInt(properties.maxccn)){
ant.fail(message:
"Maximum CCN for a method was exceeded, value was ${maxccn}")
}
</groovy>
</target>
Running this task against a code base containing a method with a ccn greater than 15 will yield the following result:
$ ./run-ant.bat -Dnoget=true threshold-check
Buildfile: build.xml
init:
get-deps:
groovy-init:
javancss-init:
javancss:
[javancss] Generating report
threshold-check:
BUILD FAILED
: Maximum CCN for a method was exceeded, value was 16
Total time: 3 seconds
This example, while useful, can be enhanced by comparing coverage as well as complexity– for instance, if the coverage dropped and complexity increased, this would be a far more adequate quality gate.
Software builds are excellent mechanisms to introduce automated quality gates– and as I’ve shown you, they’re easy to implement. As your build process matures, just remember to think through these quality gates so as to avoid false negatives. Simply failing a build because of a specific metric’s value has tripped a threshold could be dangerous. In the example above, if a method’s ccn value did exceed 15, one could argue that if that method also had high coverage, then some degree of risk has been avoided.
FitNesse, a popular Web-based test and collaboration server, is an enhancement to Fit (Framework for Integrated Testing) and an
invaluable way to collaborate on complicated problems early in development.
In January, Gojko Adzic published a free tutorial (PDF) ‘Getting Fit with .NET’ to get you on your way to testing .NET applications with FitNesse.
Available online and updated last month to cover Fit.NET 1.1 including a new chapter on DoFixture, working with arrays and business objects, topics include:
Setting up a FitNesse server for testing .NET code
Writing basic tests, performing common tasks
Tips and tricks for writing better tests and making test pages easier to read
Managing content with FitNesse
Organizing tests into test suites
Most important differences between .NET and Java versions
Definitely check it out if you’re considering using (or already are using!) FitNesse in your projects.
In related news - Adzic has also released DbFit, an extension of the Fit testing framework which allows database developers to write and automate functional and acceptance tests easily. Accompanying the first version of DbFit is ‘Getting Fit With Oracle’, a short introductory guide for test-driven Oracle database development using FitNesse and DbFit.
The new cruisecontrol 2.6.1 includes 3 bug fixes and a Veto powered plug-in designed to fix multiple build dependencies.
* Fixed problem with RMI clients where ProjectConfig was not Serializable
* Fixed problem with NullPointerException writing to the log file if the config file was reloaded in the middle of a build.
* Fixed an error loading the metrics page of the report when the jaxen jar is not in the path
The Veto plug-in will check to see if a given target project is up to date with the latest changes and if not, will “Veto” the current build attempt. This Keeps projects that are dependent on one another in the correct build order.
