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! JavaOpen SourceSoftware Development