The Disco Blog

Agile testing is about two things: a whole life-cycle and whole team approach to testing. The whole life-cycle aspect stresses leveraging testing throughout a hip process as opposed to a distinct period. Likewise, a whole team approach welcomes all parties to the quality table as everyone (yes, that means all stakeholders) accepts responsibility for building in quality.

While traditional software methodologies have the tendency to segment groups into logical units of responsibility, agile teams favor a more collaborative approach that facilitates working along side various people and groups containing differing skill sets and expectations. That is, for example, the client begins to take responsibility for elaborating expectations through a working effort to understand how the process unfolds. What’s more, by working closely with a client, a team can better understand what is needed and why. As opposed to a test document fashioned from a bogue requirements document (often times done by various teams working separately), leveraging a story in a collaborative manner ensures all parties are effectively on the same page. Thus, the customer (or some proxy there of), development, and QA are working together in the process of constructing stories and indeed leverage the same stories for all related assets.

Because it’s their bag, when Agile teams embrace stories as a fundamental means as to conveying requirements (i.e. features) along with a means for validating them, a natural tendency is for all parties to begin to own quality. That is, since everyone is aware of how to validate a feature, everyone begins to practice validating such features. In essence, a story facilitates leveraging both TDD and functional testing (which are also both automated and exercised via CI) .

What’s more, when the whole team both works together off of the same artifacts that are continuously verified, everyone can better understand the meaning of “done” — that being the question “is feature x finished and ready for the client (or clients) to have?” Of course, if everyone has utilized the same artifact (i.e. a story!) for both building and verifying a client’s expectations, then it is quite easy to check if the feature is done.

Thus, the whole team approach that leverages stories:

• ensures all hip parties see and understand the “big picture” of a particular project
  • that is, why someone wants an application (and its related features) built, which in turn further facilitates whole team ownership (along with more effective testing!)
• helps teams figure out the definition of done

Obtaining these benefits is a matter of providing a means for all parties on a team to collaborate, which is often found in leveraging a story. Plus, visibility into overall team progress as facilitated via CI and automation. The whole team approach also meets the original goal of software testing — that being the assurance that high quality code is delivered to interested parties. Teaming also reduces the tendency to throw up barriers that often plague efficiency.

Agile testing boils down to two fundamental changes, baby, that differentiate it from traditional software testing — both the notion that testing isn’t a phase but a whole life-cycle approach and that the entire team works together towards shared goals. Agile testing complements a highly efficient software development life-cycle and ultimately produces better software faster.

Are you building hip RESTful services in Grails that leverage XML? Because it’s your bag, do you want to test these services, easily? If so, then I’ve got a tool for you, baby. Grails’ Functional Testing Plugin makes verifying XML based web services a snap, baby!

This handy dandy plug-in along with Groovy’s multi-line Strings makes testing XML GETs, POSTs, PUTs, and DELETEs a breeze with as little code as possible. To get started, you must first install the plug-in like so:

$>grails install-plugin functional-test

Next, create a functional test like so:

$>grails create-functional-test MyRESTfulTest

This command will create a new Groovy file in a test/functional directory. The newly generated Groovy class is an instance of an old style JUnit 3.x test — accordingly, from here you can implement simple test methods in Groovy that have a lot of special methods at their disposal.

For example, to verify an HTTP GET to a RESTful service you can simply write:

void testRESTfulGET() {
 get('/currentComnWidgRes/1200992722')
 assertStatus 200
 assertContent """<?xml version="1.0" encoding="UTF-8" ?>
   <list><currentComnWidgRes id="1200992722">
   <effectiveDate>2009-04-30 00:00:00.0 EDT</effectiveDate><nib>4348.23</nib>
   </currentComnWidgRes></list>"""
}

Note the call to the plug-in’s get method; plus, note how I can compare the resulting response (in XML too, baby) via the assertContent call that can take a multi-line String — isn’t that a snap?

POSTs are as easy too — simply leverage the plug-in’s post method and have at it, man!

void doRESTfulPOST(){
 post("/currentComnWidgRes/"){
  body{
    """<?xml version="1.0" encoding="UTF-8" ?>
      <currentComnWidgResid="6969"><nib>-90.0</nib>
      <effectiveDate>2009-04-30</effectiveDate>
      </currentComnWidgRes>"""
    }
 }
 assertStatus 200
 assertContent """<?xml version="1.0" encoding="UTF-8" ?>
   <currentComnAcctRes id="6969">
   <effectiveDate>2009-04-30 00:00:00.0 EDT</effectiveDate>
   <nib>-90.0</nib> </currentComnAcctRes>"""
}

Note, the post method takes a closure where you can set the body via another closure and like before, you can easily verify HTTP status codes and responses.

Running the plug-in is simple too — simply type:

$>grails functional-tests

This command is quite handy as it fires up an instance of your web application; thus, the Grails Functional Testing plug-in makes functional testing, well, easy. What’s not to like about that?

Occasionally during the course of writing a hip easyb story or specification, you might run into a condition that requires a forced failure. That is, based upon some behavior of the code under verification, you might explicitly want easyb to fail a particular scenario. For example, because it’s my bag, I have a then phrase within a scenario that contains a conditional — if something is true then verify some result; however, if something is false, then force a failure. It can be coded like so:

then "the cell returned should be a date type", {
 sndcells = sheet.getRow(1)
 dtype = sndcells[2].getType()
 if(dtype == CellType.DATE){
  dt = sndcells[2].getDate()
  dt.getTime().shouldBe 1201737600000
 }else{
  fail "the type obtained wasn't a date, but was a ${dtype}"
 }
}

In the code above, which is a copasetic snippet of a larger story on parsing an Excel template, I’m verifying that I can obtain a Date type from a particular cell represented as a string (i.e. 1/31/2009). As you can see, if the dtype variable is of a desired type (i.e. Date), I can easily validate it via the shouldBe phrase. If for some reason, however, the cell I expect isn’t a date, I can force easyb to fail by using the fail phrase, which takes a String (note how you are free to use Groovy’s groovy GString feature in the phrase as I’ve done with ${dtype}).

Of course, I could have omitted the else clause entirely; however, in that case, I wouldn’t explicitly know that a particular scenario failed! Can you dig it, baby?

The easyb team is proud to have won the 19th annual Jolt award! Because it’s our bag, easyb won in the Testing Tools category; what’s more, the other tools in this category were a stellar bunch including two of our favorites — Sonar and Atlanssian’s Clover. Congratulations to all the Jolt award winners!

It’s been a blast of a journey since we first released easyb, baby and the best is yet to come! Most importantly, thanks to the easyb community for all your support — we couldn’t have done it without you, man!

The easyb team is proud to announce version 0.9.5 is now live. It has been a long time coming and this version is jam-packed with new features, baby! Behavior driven development in Java just can’t get any more fun (nor could it get any easier)!

At a high level, this version includes:

• HTML reports
• Just pass in the -html flag via the command line or specify the reporting format as html via the Ant/Maven task
• Enhanced exception reporting
• easyb offers two options:
• -e for a full exception stack trace
• -ef for exception stack trace filtering — that is, a lot of the noise associated with a Groovy exception stack is filtered out
• Support for ignoring scenarios
• ignore is a hip keyword now in stories and it can take as an argument a scenario name, a list of scenario names, and even a regular expression
• Pretty printing
• Pass in the -prettyprint flag and the output will be nicely colored, baby!
• Narratives support non underscores
  • as_a can alternately be
    written as as a along with i want and so that
• Numerous API improvements along with bug fixes!
• For instance, the ensureThrows takes a list of exceptions now
• This version leverages Groovy 1.6.0

Please note, this version has changed the package names — previous versions’ package names started with org.disco.easyb.*. We’ve corrected things and removed the disco portion; consequently, all easyb package names are org.easyb.*. This version also has an enhanced plug-in mechanism (which leverages a new keyword, using) for integration with other frameworks — for instance, we anticipate these changes will facilitate easier integration with Grails 1.1.

Thanks to the community for numerous suggestions, comments, and patches! We anticipate that this will be the final version before we release a 1.0 candidate. So what are you waiting for? Download easyb 0.9.5 now and have a blast, baby!

A disconnect between the stakeholders who define requirements and the developers who implement them has long plagued software development, baby. In recent years, frameworks based on dynamic languages (like Groovy and Ruby) and domain-specific languages have come a long way in bridging this stakeholder-developer gap by making code read more like normal language. One such framework is easyb, which enables teams to collaboratively verify behavior of Java (and Groovy!) applications in a more natural way.

This May 7th and 8th in Reston, Virginia, I am delighted to offer a 2 day hands on course focusing on BDD with easyb. This hip course features 16 hands-on workshops where you’ll understand the benefits of collaborative stories implemented with easyb and how this framework makes collaboration easy (and fun!). You’ll learn how to validate applications in the style of Test Driven Development (TDD) that facilitates mocking, user acceptance testing with Selenium, database dataset management with DbUnit and even ascertaining code coverage.

Throughout the program, you’ll be challenged with lab exercises that’ll drive home various techniques of Behavior Driven Development with easyb along with tools and related processes. You’ll verify Java code as well as web applications and leverage a bevy of tools including Selenium, DbUnit, and various mocking libraries and techniques. What’s more, you will learn how to combine these tools in an effort to create highly structured deep verification assets that exercise applications from a micro level to a macro level.

Regardless if you’re a developer or a tester and regardless of your experience with BDD and easyb you’re bound to learn something new and exciting in this course. Ultimately, by applying a more collaborative platform in your software projects, you’ll produce better code more quickly. So what are you waiting for? Sign up today while there is still room!

The question of how to test for exceptions comes up quite frequently. While there’s more than one way to skin a cat, so to speak, man, I’ve found that documenting intent is often more helpful in quickly conveying behavior.

Case in point, with the advent of JUnit 4’s expected attribute of the @Test annotation, it’s quite easy to concisely specify which exception a given test case should throw.

For example, below is JUnit 4’s exception handling shortcut in action:

@Test(expected=RuntimeException.class)
public void testComputeIrr() {
  double [] cashflow = {100.0, 90.0, 80.0, 70.0};
  FinancialMath.computeIrr(cashflow, 0.01);
}

In this case, the testComputeIrr method should throw a RuntimeException (due to the lack of a negative cash flow in position 0). Using this technique, however, does impair the intent slightly of the code under test as the inherent compactness of the attribute syntax requires some expanded thinking.

Antony Marcano recently wrote a hip blog entry entitled “Writing tests for Excepted Exceptions - a slightly different way…” in which he demonstrates a more expressive technique for verifying exceptional circumstances. His preferred style of exception verification also happens to be mine; that is, utilize a try/catch phrase, which wholly expresses the test (WET) resulting in a clearer picture of expected (or non expected behavior).

For example, WET-ing the first example would yield a more effusive test, but it serves as clearer, more hip documentation:

@Test
public void testComputeIRR(){
 try{
  double [] cashflow = {100.0, 90.0, 80.0, 70.0};
  FinancialMath.computeIrr(cashflow, 0.01);
  fail("computeIRR didn't throw an exception");
}catch(Throwable thr){
  assertTrue("exception type should be RuntimeException",
     thr instanceof RuntimeException);
 }
}

Incidentally, easyb also supports a shorthand mechanism for verifying exceptions — for instance, I can rewrite the first JUnit example as:

given "a cash flow with all positive values", {
 cashflow = [100, 90, 80, 70] as double[]
}
then "the IRR computation should throw a RuntimeException", {
 ensureThrows(RuntimeException){
  FinancialMath.computeIrr(cashflow, 0.01)
 }
}

While easyb’s expressiveness largely meets the notion of WET (that is, the then phrase is providing additional context to the code) you can, of course, be WETer and avoid the ensureThrows clause like so

given "a cash flow with all positive values", {
 cashflow = [100, 90, 80, 70] as double[]
}
then "the IRR computation should throw a RuntimeException", {
 try{
  FinancialMath.computeIrr(cashflow, 0.01)
 }catch(e){
   e.shouldBeA RuntimeException
   e.getMessage().shouldBe "Only positive cashflows"
 }
}

In the code above, I’m verifying the same behavior, albeit in a more demonstrative manner, plus, I’m able to ensure the exception is providing a specific message. You can, by the way, also achieve the same result using the 2nd more expressive JUnit example.

Documenting intent is often more helpful in quickly conveying hip behavior as it serves to clearly express the tale or test or story (wholly expressing the story doesn’t work so well as an acronym though). Applying DRY principles might yield fewer lines of code (and I’m a big fan of less code) but in some cases it pays to be copasetically WET, baby.

easyb has been nominated as a 2008 Jolt award finalist, baby! I know I speak for the entire easyb team when I say we are truly honored to have been considered for such prestigious award.

The awards are segregated into categories and easyb is in the Testing Tools category along with such tools as Atlanssian’s Clover and Sonar. Indeed, it appears that easyb is one of a few open source nominations in the entire list of impressive products and companies.

The winners will be announced at the SD West conference on March 11, 2009. I’ll be there, along with fellow easyb-ist Rod Coffin, presenting a tutorial on easyb entitled “Set your User Stories Free with Groovy’s easyb” — it promises to be a hip time, baby!

I’ve been asked on more than one occasion if easyb supports code coverage. The answer is a copasetic yes and here’s how (using Cobertura and Ant). Code coverage, regardless of your desired tool, essentially entails three steps, namely:

• instrument your code base
• run your tests (alternately, run something as tests are necessarily a requirement)
• produce a report

Instrumenting your code base with Cobertura is straightforward — Cobertura’s documentation is quite good and you should be able to come close to having a working version with a simple copy and paste. For example, here is an instrument task in Ant:

<target name="instrument" depends="compile-source" description="instruments .class files">
 <property name="cobertura.dir" value="lib/cobertura" />
   <path id="cobertura.classpath">
    <fileset dir="${cobertura.dir}">
      <include name="**/*.jar" />
    </fileset>
   </path>
 <taskdef classpathref="cobertura.classpath" resource="tasks.properties" />
 <delete file="./cobertura.ser" />
 <mkdir dir="target/target-inst" />

 <cobertura-instrument datafile="cobertura.ser" todir=".">
   <fileset dir="target/classes">
     <include name="**/*.class" />
	 <exclude name="**/*Test.class" />
    </fileset>
 </cobertura-instrument>
</target>

Next, execute your easyb behaviors as normal; however, be sure to that your classpath references your instrumented .class files — otherwise, you’ll have reports telling you of 0% coverage!

<target name="coverage" depends="instrument" description="runs code coverage">
 <mkdir dir="target/reports" />
  <easyb failureProperty="easyb.failed">
	<classpath>
      <path refid="build.classpath"/>
      <pathelement path="target/target-inst"/>
    </classpath>

   <report location="target/stories.txt" format="txtstory"/>
   <behaviors dir="stories">
    <include name="**/**.story"/>
   </behaviors>
  </easyb>
  <fail if="easyb.failed" message="easyb reported a failure"/>

  <mkdir dir="target/reports/coverage-report" />
  <cobertura-report format="html" datafile="cobertura.ser"
	destdir="target/coverage-report" srcdir="src/" />
  <cobertura-report format="xml" datafile="cobertura.ser"
	destdir="target/coverage-report" srcdir="src/" />
</target>

You’ll note, man, that this task does a few things — that is, it runs my easyb stories and produces a coverage report. And that’s about it! With these two tasks defined, when you execute %>ant coverage, you’ll have code coverage reports with Cobertura that measure the coverage of your easyb behaviors. Keep in mind, you must force easyb to load your instrumented .class files — that is, your stories are not compiled but the code those stories reference (whether they be Java or Groovy) must be instrumented for a report to be generated (as those are .class files that are loaded by the Groovy runtime).

Incidentally, by applying strict BDD semantics — that is, defining stories before writing any code and then writing just enough code to have one scenario at a time pass produces 100% code coverage in every occasion that I’ve employed. Incidentally, even though one has 100% code coverage it doesn’t mean the code is defect free. Right, man?

I had such a hip time at last year’s CodeMash that I can’t wait to attend this year’s bash; what’s more, I’ll be presenting a talk entitled “Executable documentation with easyb” (hopefully with my good friend Rod Coffin), which is going to explore how easyb enables teams to develop stories in a specific format (i.e. a DSL, baby) which are then implemented as verification assets which marries the underlying application.

In this talk, those who attend will learn how to embrace collaboration and change rapidly by defining easyb stories that exercise a Java application end to end. Attendees will learn how to define specific easyb structures, how to plug them into real code, and how to run them in an automated fashion– people will see first hand how non-coders can define tests easily and how the collaboration this brings yields working software faster.

CodeMash is a unique event full of a lot of energy and myriad interesting disco dancers — plus, Cleveland is a wonderful place to visit in January. That is, if you plan on spending your visit in an indoor water park, man.