easyb

Specifications are an easy way to capture behavior in a more natural way-- they almost read like plain English.

Examples

Below is an example of using a specification to verify a Queue.

package org.easyb.bdd.specification.queue

import org.easyb.bdd.Queue

description "This is how a Queue must work"

before "initialize the queue for each spec", {
 queue = new Queue()
}

it "should dequeue item just enqueued", {
 queue.enqueue(2)
 queue.dequeue().shouldBe(2)
}

it "should throw an exception when null is enqueued", {
 ensureThrows(RuntimeException.class) {
  queue.enqueue(null)
 }
}

it "should dequeue items in same order enqueued", {
 [1..5].each {val ->
  queue.enqueue(val)
 }
 [1..5].each {val ->
  queue.dequeue().shouldBe(val)
 }
}	

Below is an example of validating the ZipCodeValidator object using the specification format rather than a story format (which was done on easyb's homepage).

package org.easyb.bdd.specification.zip

import org.easyb.bdd.zip.ZipCodeValidator

before "initialize zipcodevalidator instance", {
 zipvalidate = new ZipCodeValidator();
}

it "should deny invalid zip codes", {
 ["221o1", "2210", "22010-121o"].each {zip ->
  zipvalidate.validate(zip).is false
 }
}

it "should accept valid zip codes", {
 ["22101", "22100", "22010-1210"].each {zip ->
  zipvalidate.validate(zip).shouldBe true
 }
}

A specification may also be tagged as "pending" -- thus providing an indication of status. A pending specification is one which doesn't have an implementing closure for behavior like so:

package org.easyb.bdd.specification

it "should show up as a pending specification"

For more specification examples, check out easyb's source -- easyb uses easyb to validate itself!