Forcing a failure in easyb

how-to
May 27, 20092 mins

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 <a href="<a href="https://easyb.org/dsls.html">https://easyb.org/dsls.html</a>">then</a> 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:

<pre class="prettyprint"><code>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 <a href="<a href="https://www.theserverside.com/news/thread.tss?thread_id=44442">https://www.theserverside.com/news/thread.tss?thread_id=44442</a>">GString</a> 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?

You can now follow The Disco Blog on Twitter, baby!
andrew_glover

When Andrew Glover isn't listening to “Funkytown” or “Le Freak” he enjoys speaking on the No Fluff Just Stuff Tour. He also writes articles for multiple online publications including IBM's developerWorks and O'Reilly’s ONJava and ONLamp portals. Andrew is also the co-author of Java Testing Patterns, which was published by Wiley in September 2004; Addison-Wesley’s Continuous Integration; and Manning’s Groovy in Action.

More from this author