Mastering the art of command line jujitsu is something every developer (regardless of OS) should strive for. While OS UIs are becoming more and more slick and helpful tools are abundant, possessing the ability to drop into a console and efficiently knock something out (find . -iname *.java | xargs egrep -i “todo” anyone?) has come in handy, for me at least, on more than one occasion.

For instance, every modern IDE now has a plug-in that facilitates working with Subversion– in fact, when I made the switch to Subversion from CVS a fews years back, I initially failed to even learn the Subversion commands– my favorite tools did it all for me graphically! Yet, in some cases I found myself distrusting the implementations these tools provided– for instance, one of my favorite CVS commands was cvs -nq update, which effectively tells you what’s changed in your local sandbox as compared to the tip of the CVS repository. This, of course, is handy in figuring out what you plan on committing; hence, I would run this command before a cvs commit so as to filter out unneeded changes.

This developmental cadence of making changes and checking them against the tip (and consequently committing them) is actually common among SCM systems– the cadence has three steps:

• updating a local sandbox to reflect what is in a repository
• understanding what has changed locally
• committing local changes into a repository

With Subversion, these three steps can be achieved via the command line with three commands:

• svn update
• svn diff
• svn commit

The svn update command takes any changes in a Subversion repository and pushes down to a local sandbox. For instance, if more than one person is making changes and committing those changes into a repository, when another person runs the svn update command, those changes will be literally downloaded into that person’s sandbox.

Using the update command is as easy as opening up a console and typing:

tty:~/dev/projects/easyb/ yts$ svn update

If there are changes in the repository, you should see some scrolling text like so:

U    maven-plugins/maven-easyb-plugin/src/main/java/org/easyb/maven/StoryReportMojo.java
U    maven-plugins/maven-easyb-plugin/src/site/apt/usage.apt
U    maven-plugins/maven-easyb-plugin/src/it/story-report-location-test/pom.xml
U    maven-plugins/maven-easyb-plugin/src/it/site-examples-test/pom.xml
U    intellij-plugins/easyb-plugin/easyb-plugin.iws
U    intellij-plugins/easyb-plugin/src/main/java/org/easyb/plugin/ui/EasybPresenter.java
U    intellij-plugins/easyb-plugin/pom.xml
Updated to revision 329.

Note, the U means updated– there are other characters for new files added, merged, in conflict, etc. What’s key here is that by running the update command, your local sandbox is in sync with what’s on the server. Running this command often often means you’ll probably avoid conflicts too!

After you’ve made some local changes, it’s often times helpful to capture what those changes were– if you’ve been working for any length of time or working with more than one file, you’ll most likely find the diff command indispensable.

Like the update command, diff can be run via the command line like so:

tty:~/dev/projects/easyb/ yts$ svn diff

This command will compare what’s in the repository with what’s in a local sandbox; what’s more, it’ll report on the exact changes as follows:

Index: behavior/groovy/org/disco/bdd/prototype/FixtureFeature.story
===================================================================
--- behavior/groovy/org/disco/bdd/prototype/FixtureFeature.story        (revision 322)
+++ behavior/groovy/org/disco/bdd/prototype/FixtureFeature.story        (working copy)
@@ -4,7 +4,7 @@
 description "this story is fleshing out fixture logic for scenarios"

-each "some description" , {
+every "some description" , {
     given "a value", {
         value = 12
     }
Index: src/groovy/org/disco/easyb/StoryBinding.groovy
===================================================================
--- src/groovy/org/disco/easyb/StoryBinding.groovy      (revision 322)
+++ src/groovy/org/disco/easyb/StoryBinding.groovy      (working copy)
@@ -102,7 +102,7 @@
       listener.describeStep(description)
     }

-    binding.each = {  description = "", closure = {} ->
+    binding.every = {  description = "", closure = {} ->
         beforeScenario = closure
     }
     return binding

As you can see in the text above, the local code (labeled as “working copy”) has changed the each call with every, which appears in revision 322 of the repository.

Once you’ve reviewed these changes and are happy with what you’ve got, you can then proceed to push these changes into the repository via the svn commit command– of course, this assumes you’ve run a local build and it passed successfully, right?

tty:~/dev/projects/easyb/ yts$ svn commit -m "updated dsl to use every instead of each"

Note that the commit command can take a flag (-m) that enables you to specify a comment. You should see some text indicating the changes are being pushed into the repository.

Sending        easyb/behavior/groovy/org/disco/bdd/prototype/FixtureFeature.story
Sending        easyb/src/groovy/org/disco/easyb/StoryBinding.groovy
Transmitting file data ..
Committed revision 325.

Note how these changes increment the revision number in Subversion– this is key as all commands allow you to work with various revisions (via flags); hence, by knowing a particular revision, you can logically branch if needed.

These three Subversion commands will come in handy if you aren’t already using them; hence, learn them now! Indeed, for becoming one with the command line is the path to enlightenment.

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!

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.

InformIT has published a Q&A with Stelligent’s CTO, Paul Duvall. Paul shares his thoughts on adopting CI, the future of CI, and of course, his thought provoking blog entry. Check it out!

Hudson is an open source CI server that offers quite a few compelling features (in addition to its easy setup and configuration) that come in handy from time to time. For instance, Hudson offers a Groovy plug-in that facilitates executing arbitrary Groovy scripts (or code) as a part of a build.

Groovy can be quite useful for simple tasks, which when written in some other form (like an Ant script) requires a lot of plumbing– for example, recently, as a part of a CI project setup, another dependent project’s directories were becoming read-only due to an SCM feature. Consequently, a child project couldn’t write to the filesystem.

This problem was easily solved using Groovy (plus a little Ant)– a triggered build executes a small Groovy script that uses Ant’s chmod task to make target directories read-write enabled. As you can see, the fix requires 2 lines of code (which could, arguably, be reduced to one):

def ant = new AntBuilder()
ant.chmod(dir:"./ci09_i/ui/rep2/reports/", perm:"ugo+rw", includes:"**/*.*")

Hudson’s so Groovy that it’s hard to ignore this CI server as a viable option!

Since Selenium was introduced a few years back, it has continued to wow developers with how easily a user acceptance test can be knocked out– simply fire up an instance of a Selenium server in the background and then either write a table test or a RC style test– it’s that easy.

RC style testing is particularly powerful as you have full access to programming languages– for instance, with RC, you can write a functional web test in Java by leveraging a framework like JUnit or TestNG. But what’s often lacking with testing frameworks is a more natural way of expressing behavior– or indeed, scenarios and stories.

For instance, a user acceptance test is really a scenario– a user logs into a website, purchases an item, pays, and logs out. That was a sunny day scenario– there are other scenarios that deal with various other paths– user fails to pay, credit card was invalid, etc. All of these scenarios are logically a story– a story about buying something.

Using a standard scenario language, I can more specifically write a scenario (in a story regarding a website for race registrations) like so:

• given a user is on the race report page
• when someone enters a first name and last name in the race report form for someone who has signed up for a race
• then they should receive a list of all races that person has singed up for

That is a happy day scenario isn’t it? One particular negative path would be:

• given a user is on the race report page
• when someone enters a first name and last name in the race report form who hasn’t signed up for any races
• then they should receive a message indicating the person hasn’t signed up for any races

These scenarios can be easily created using easyb, which is a BDD framework for the Java platform– easyb leverages a domain specific language (or DSL) which supports the following syntax for scenarios:

scenario{
 given "", {}
 when "", {}
 then "", {}
}

This DSL is highly flexible– you can chain phrases together with an and phrase and you can have multiple givens or whens or thens if you’d like. Also too, the scenario phrase isn’t required either.

The DSL makes the assumption that scenarios are in files that are either named YourNameStory.groovy or YourName.story– note that YourName is what ever you’d like.

Using easyb then, I can create a story file, which contains two scenarios– my file will be called RaceReport.story and I’ll start by defining two scenarios:

scenario "a valid person has been entered", {}
scenario "an invalid person has been entered", {}

Given that I plan to leverage Selenium, I’ll have to introduce a few new phrases– for instance, a then one that shuts down Selenium.

I’ll start the RC instance in a given phrase like so:

given "selenium is up and running", {
 selenium = new DefaultSelenium("localhost",
  4444, "*firefox", "http://acme.racing.net/greport")
 selenium.start()
}

Note how I’m connecting to a server instance running on the same machine, which will utilize Firefox.

Next, I can chain two when clauses to simulate a user interacting with the report page.

when "filling out the person form with a first and last name", {
 selenium.open("http://acme.racing.net/greport/personracereport.html")
 selenium.type("fname", "Britney")
 selenium.type("lname", "Smith")
}

and

when "the submit link has been clicked", {
 selenium.click("submit")
}

My then clause then verifies that 4 race instances have been returned for my user– note how I’m able to use a nice Groovy for loop that uses a positional index to grab items from a list and from an XPath expression. Not bad, eh?

then "the report should have a list of races for that person", {
 selenium.waitForPageToLoad("5000")
 values = ["Mclean 1/2 Marathon", "Reston 5K", "Herndon 10K", "Leesburg 10K"]
 for(i in 0..<values.size()){
  selenium.getText("//table//tr[${(i+3)}]/td").shouldBeEqualTo values[i]
 }
}

Lastly, I need to shut down selenium:

and

then "selenium should be shutdown", {
 selenium.stop()
}

The entire first scenario looks like this once you put it all together:

scenario "a valid person has been entered", {

 given "selenium is up and running", {
  selenium = new DefaultSelenium("localhost",
   4444, "*firefox", "http://acme.racing.net/greport")
  selenium.start()
 }

 when "filling out the person form with a first and last name", {
  selenium.open("http://acme.racing.net/greport/personracereport.html")
  selenium.type("fname", "Britney")
  selenium.type("lname", "Smith")
 }

 and

 when "the submit link has been clicked", {
  selenium.click("submit")
 }

 then "the report should have a list of races for that person", {
  selenium.waitForPageToLoad("5000")
  values = ["Mclean 1/2 Marathon", "Reston 5K", "Herndon 10K", "Leesburg 10K"]
  for(i in 0..<values.size()){
   selenium.getText("//table//tr[${(i+3)}]/td").shouldBeEqualTo values[i]
  }
 }

 and

 then "selenium should be shutdown", {
  selenium.stop()
 }

}

That’s pretty easy, don’t you think? Of course, my next step is to implement some additional scenarios, such as negative paths with an non-existing runner, etc.

When I run this via the easyb runner, I can get a story printout that looks something like this:

12 behavior steps executed successfully
 scenario a valid person has been entered
  given selenium is up and running on website
  when filling out the person form with a first and last name
  when the submit link has been clicked
  then the report should have a list of races for that person
  then selenium should be shutdown
 scenario an invalid person has been entered
  given selenium is up and running on website
  when filling out the person form with a first and last name
  when the submit link has been clicked
  then the report should have a list of races for that person
  then selenium should be shutdown

The scenarios are slight variations of one another, hence the report looks quite similar — each step is the same, just the data varies.

Functional web stories are a powerful mechanism to verify the proper behavior of web applications from a user’s standpoint. Combining a framework that supports stories and scenarios with Selenium yields an easy way to deliver software more quickly and collaboratively.

It seems the build platform debate continues to heat up with Steven Devijver’s posting on the DZone entitled “What’s Wrong with Build Systems in Java Today?” where he previews a build platform that builds upon Ant and Maven 2 and adds, as he states:

Better-than-Maven 2 JAR and project dependency management, No XML, and Integration of Ant, Maven 2, Gant, Buildr, Rake, Grails, … projects in multi-project builds

Clearly, in the Java space, Ant is the de-facto build platform; consequently, the future of build languages will most likely need to leverage the extensive infrastructure in place to support Ant– dropping XML is key should you require a more imperative style of building things. Dependency management has always been a splintered solution ranging from Ivy to Maven’s declarative dependency framework to Ruby’s gems– all interesting and viable solutions, which makes his statement all the more interesting.

All in all, these are exciting times as dynamic languages are enabling a complete change in the way we define software builds, which will ultimately lead to tools that make building software (that is, compiling, testing, inspecting, deploying, etc) easier.

Steven Devijver (one of the co-creaters of the Grails framework and an all around super guy) recently interviewed me concerning easyb. easyb is a behavior driven development framework for the Java platform, which makes use of a specification based Domain Specific Language– by doing so, easyb aims to enable executable, yet readable documentation. In fact, as Steven coined, easyb enables conversational testing, which I think is a fitting term!

Read the interview and see what you think– or better yet, try easyb out for yourself!