This was discovered with Clover 2.2.1

We have a build.xml file with the following pseudo-flow:

• clover-setup
• // this causes all future compilations to use the clover compiler to instrument the files.
• compile
• javac _all_source_
• test_A
• javac _unit_test_source_ // yes, this is a subset of all source
• junit _unit_tests_
• 
  
• test_B
• javac _unit_test_source_ // yes, this is a subset of all source, and redundant with test_A
• junit _integration_tests_
• clover-report
• NO DATA!
  

By inserting < clover-log / > at the end of test_A and test_B, I figured out what was going on.

1. after test_A, we have a nice coverage level
2. but at the end of test_B, we have been reset back to 0

My hypothesis is that there is a bug in Clover that causes it to:

a) wipe out all of the coverage data thus far when new code is compiled.

b) prevent new code from updating the coverage database.

And sure enough, by removing the javac compilation step from test_B, we have an accurate combined coverage report.

Moral of the story:

1. Do all of your compiling before you run any of your automated tests
2. < clover-log / > is your friend.

Jim York, a long time Stelligent friend, a Certified Scrum Trainer and lean and agile coach, is conducting a Certified ScrumMaster class May 5-6 in Vienna, VA.

Learn the essentials of working as ScrumMasters, Product Owners, and Scrum team members in this highly-interactive 2-day class. Jim creates an energized learning environment where participants engage in discussion, hands-on simulations, and role play to explore the nuances of Scrum in action. More than an intellectual exercise, Jim challenges attendees to connect Scrum practices to their underlying guiding principles. This class provides what you can’t get from a book — guided experiential learning in realistic scenarios.

Sign up today as space is limited!

Calling all blokes and sheilas– this year’s Asia-Pacific CITCON will be in Melbourne, Australia on June 27th & 28th– registration is now open so claim your spot before space runs out (space is limited to the first 150 tall poppies, surfies, and all around dags)!

If you dream about CI, yabber about TDD, live for BDD, or constantly think about automated deployments, then the Continuous Integration and Testing Conference is a ripper of a time, mates! The conference is free and is run as an OpenSpaces event, so there’s no reason not come. Remember, space is limited so sign up now!

Let’s say you have a fairly complicated build structure, with multiple batch files that fire off different aspects of the build (even if, at the end of the day, they just call ant).

And let’s assume that for various historical reasons, these batch files encapsulate their environment variables using SETLOCAL and ENDLOCAL.

At first glance, this is a pretty cool way to scope out your environment variables. But then, you find out that Hudson determines if a build has succeeded or failed by looking at the %ERRORLEVEL% environment variable. If it is not 0, the build has failed.

Uh oh. Your build is failing, but the moment ENDLOCAL is called, %ERRORLEVEL% is set back to its previous value, which, most likely, will be 0.

Given this situation, how do you get the %ERRORLEVEL% back up to Hudson? Well, don’t call ENDLOCAL. Instead use:

EXIT %ERRORLEVEL%

at the end of your batch file. This works because there’s an implicit ENDLOCAL at the end of your batch file, and EXIT will return the ERRORLEVEL as the exit value.

So you want to build a set of automated tests using Selenium against your webapp. I’m going to assume you have already figured out how to launch your app and set the database into a known state.

Now, you want to write some tests that mimic visiting the website and interacting with the UI in various ways.

I’ve been playing with Selenium quite a bit recently, and I’ve assembled a short list of things that will hopefully make other people’s lives easier.

Building your Tests : Navigation

• Use Selenium IDE (Firefox Plugin) to develop the navigation flow for you. The last thing you want to be doing is debugging your navigation steps in your test case so you can get to the target. With Selenium IDE, you get your app running, and record the clicks and actions you take to get to your destination.
• When you finish recording, you can export your test as a java program, or in several other languages. Take advantage of this!
• To click on a link - if you assume you have a link like: < a xhref=" Your Text Here < / a > you can get the Selenium browser object to activate the link by issuing browser.click(”Your Text Here“);

Building your Tests: Validating Results

Selenium has XPath support, and XPath is a very powerful tool for processing HTML. But the syntax of XPath is quite arcane, and I spent waaaaaay too much time trying to decipher what was wrong with my XPath query.

• Use XPath Checker (firefox plugin) - go to the results page, and control-click to bring up the XPath Checker browser. Then you can experiment with various XPath expressions until you get the one that works for your particular page and content.
• To find if text appears anywhere on the page (also known as the quick-and-dirty method) - use assertTrue(browser.isTextPresent(”Your Text Here“));
• To find if text appears in a specific sub-location, the easiest way I have found is:
• assertEquals(”Text“, browser.getText(”//table[@id=’whatever’]//tr[2]/td[1]”));
• Selenium is smart about pulling all of the text out of a set of cells, subtags, whatever, so even if that text was nested inside a div, a span and a link, it would still find it.

Running Your Tests

• You can’t use Selenium inside your tests unless the Selenium RC Server is running - launch it before you start your tests, like you would Cargo, your database, etc.
• It’s a proxy, so you have to make sure that the port you use in your code (default: 4444) is the same as the port that Selenium server is running on.

Hopefully this will help some future person get up to speed faster.

Wednesday, April 16th: 3:00pm – 4:00pm ET

Are you seeking to improve the development practices of your organization? Has your team adopted a continuous integration strategy? Are you looking for the best tool to manage your builds? If so, this webinar hosted by Paul Duvall, author of the Jolt award-winning book on Continuous Integration, needs to be penciled into your calendar.

Entitled, “Continuous Integration: Improving Software Quality and Reducing Risk,” the webinar will tackle key topics and practices in the areas of continuous database integration, testing, inspection, deployment and feedback.

If you’re a lead engineer, architect, or development manager striving for greater confidence in your software product, you should tune in to find out more about how CI helps reduce key project risks such as late defect discovery, low-quality software, lack of visibility, and lack of deployable software. Additional topics on the discussion table include:

• How to use CI leveraging a combination of CI, build, test and inspection tools
• How to make integration a “non-event” on your software development projects
• How to reduce the amount of repetitive processes you perform when building your software
• Effective practices and techniques for using CI with your teams

Registration is required for this event and available at: https://www1.gotomeeting.com/register/656993026?Portal=www.gotomeeting.com

John Ferguson Smart, a long time friend of Stelligent and author of O’Reilly’s “Java Power Tools” will be holding the Java Power Tools bootcamp this May 12th through the 15th in San Francisco, CA. The timing couldn’t be better– it’s right after JavaOne! The course is 4 days of intense hands on workshops covering TDD with JUnit 4, all things Maven 2, CI with Hudson, and much, much more! For more information, visit the course website and sign up today!

The software development process is a big black box for basically everyone on the planet earth, except for a few, proud individuals who speak geek and wear silly tee-shirts. To everyone else who doesn’t read code or wear silly tee-shirts but work with people who do, the last bit of sanity they have is during the time they get to tell development what they want. After that, stakeholders are left praying that at the end of the developmental process, they get something out of it that works. More often than not, if that developmental process takes a long time, stakeholders don’t get want they want.

Along came iterative processes and customer involvement and things got better. A little. Stuff still broke. And developers still had horrible manners and wore silly tee-shirts. A few of them also appeared not to have learned basic hygiene.

Then came test driven development. Developers’ manners were the same and they still wore silly tee-shirts, but at least the code wasn’t as horrible. Hygienic concerns remained.

Iterative processes became more popular and the stakeholder wanted more. The stakeholder wanted visibility into that black box that those silly tee-shirt wearing developers called the “dev cycle” or the “software construction phrase” but what the normal people called “sit tight and pray a lot” time or “oh gosh, what’s this gonna cost this time?”. After all, they were paying for it and the tee-shirts those developers wore didn’t make any sense (hygienic concerns not withstanding).

Along came the gurus shouting “traceability!” which makes total sense since stakeholders are paying the bill. Emboldened, stakeholders declared:

“When a user selects 3 items, then they should receive a 10% discount.”

Heads nodded. The look of approval was unmistakable. Business was accelerating forward and everyone was happy.

Soon, stakeholders were summoned. The silly tee-shirt wearing developers proudly showed the stakeholders a test case proving the requirement was met and even tested.

The stakehoders looked puzzled. Confused even. And they weren’t trying to read those silly tee-shirts or ponder hygienic skills. Development put their finest heads together and clarified the situation with some documentation:

The stakeholders did their best to understand what they were looking at. In fact, the code even tried to convey more meaning. Yet, no matter how hard they tried, the stakeholders couldn’t speak geek. They couldn’t read the code. They couldn’t laugh at the tee-shirts. They couldn’t not brush their teeth.

Then one of the stakeholders (who used to wear silly tee-shirts) got an interesting idea– why not leverage the same language for both defining the requirements and validating them? In fact, by leveraging BDD constructs and paying attention to what was originally asked for, things can become quite easy.

This is what was originally asked for:

“When a user selects 3 items, then they should receive a 10% discount.”

The key word being should– in fact, the mechanism by which the requirement was requested sounded an awful lot like a story, which could be written like so:

Then working with a few developers (who showered that morning), the stakeholder convinced them to author the story using a BDD framework (like easyb), which yielded a file containing the requirements like so:

After the code was implemented, the stakeholder was pleased. Other stakeholders were summoned. Other developers were also summoned. Soon heads nodded. Approval was in the air. Business had been accelerated and all involved parties understood each other, for indeed, stakeholders could read what development had finally produced:

Stakeholders rejoiced! Developmental jollification ensued. Speaking geek was no longer needed. Things were written in plain English. Those silly tee-shirts still didn’t make sense, but it didn’t matter anymore– stakeholders got what they wanted. They got validation. They got assurance that indeed their requirements had coverage. They didn’t get some of the developers to shower, but they weren’t asking for miracles, just progress. The “sit tight and pray a lot” time became a collaborative effort. BDD had saved the day.

If you are using IE and trying to configure Matrix-based security, beware. It doesn’t work no matter how many times you click the Add button.

At this point, don’t panic. Rather than changing the config.xml and manually adding all the users and setting their permissions, download Firefox, and you will be easily able to configure the same as shown below:

Hello!

Andy has graciously invited me to post here at testearly.com, and I thought I would start off with some of my experiences with configuring Hudson. This is a crosspost from my blog, but I suspect it will get a lot more traffic here.
…

Let’s say you’re using Hudson as your build/Continuous Integration tool. And let’s assume you have some jobs running inside Hudson that you want to keep running, even if the build machine blows up. You probably want to maintain:

• Hudson itself
• All the plugins
• The overall configuration
• The per-job configuration

Naturally, then, your thoughts should turn to “How do I put the Hudson configuration into source control?” Here’s what you do:

1. Make sure your builds are configured and working to your satisfaction, in a directory that I will from now on refer to as HUDSON_HOME.
2. Copy the entire HUDSON_HOME directory tree to a temporary location called “versioned_build”
   1. In the versioned_build directory, you’ll find the jobs directory, and under that, a directory for each job.
   2. Inside each job directory, you’ll find configuration .xml files and other miscellaneous files, and you’ll find two subdirectories:
      • workspace
      • builds
   3. Empty those two subdirectories of all files, but do not delete the subdirectories.
3. Repeat this “clean out” process for each job.
4. import the entire “versioned_build” directory tree into source management.

Now, you have your Hudson configuration in source control. You can start it up, and assuming HUDSON_HOME is set right (see below), you should see your dashboard, and your jobs listed, and properly configured. Issues

• You may have to manually kick off your jobs to “prime the pump”
• Your build number will not start at 0 unless you do not archive the nextBuildNumber file
• Your HUDSON_HOME environment variable may be incorrect for your machine (see below)

HUDSON_HOME Portability For ease of checkout and maintenance, I like the following directory setup: $HUDSON_HOME/

• hudson/
  • hudson.war
• jobs/
  • Your Hudson Jobs Here
• plugins/
  • Your Hudson Plugins Here

Using this configuration, you can create a file in $HUDSON_HOME called, say, hudson.sh, which would look a little something like this:

---

#!/bin/sh
export HUDSON_HOME=.
export CVS_RSH=/usr/bin/ssh
java -jar hudson/hudson.war

---

Using this structure, and that hudson.sh script (I presume you can do something similar in Windows) gives you the following benefits:

1. Your entire Hudson system, including the Hudson war file and the launcher script are all maintained as part of the repository.
2. You don’t have to set HUDSON_HOME whenever you check the system out of source control - it’s already set by default to the current directory. As long as you run hudson.sh in its own directory, you’ll get the correct value for HUDSON_HOME

Learn from my mistakes!

• Unless you absolutely must, don’t tell Hudson where to find Ant or the JDK. If they’re on your path, Hudson will find them on its own. If you set them for your build machine, chances are that on the checkout machine they won’t be in exactly the same place