describe(“Siesta 1.2.0 with BDD support”)
BDD, or Behavior Driven Development has been all the hype for a while now when it comes to JavaScript development. One of the most known JavaScript BDD test tools is Jasmine, and it does a great job of producing readable tests. We’ve received lots of feedback from the Siesta community to add support for writing BDD tests in Siesta. Since we’re getting close to releasing the 1.2 version of Siesta (which is a pretty big release) – let’s take a look at the new BDD support in this version.
Hello BDD world
To make tests better describe what is being tested we use 3 new methods to arrange our test code. At the top level, to describe a “suite” of tests we can call t.describe, and pass it a string describing the suite and as the second argument we’ll pass a function having the test instance as its only argument.
[crayon striped=”false” lang=”javascript” nums=”false” toolbar=”false”]
describe(“My test suite”, function (t) {
t.pass(‘BDD FTW’)
});
[/crayon]
Inside the suite, we can have other sub-suites or any valid Siesta test assertion statements. To divide a suite into logical blocks, we use what’s called a spec. As in Jasmine, inside a spec you typically have sub-specs or one or more expect statements to verify your assumptions. An expect statement begins with the value to assert, followed by the matcher. See the code below for a simple demonstration.
[crayon striped=”false” lang=”javascript” nums=”false” toolbar=”false”]
describe(“My test suite”, function (t) {
var doc = document,
body = doc.body;
t.it(‘Should be possible to set a CSS class on body’, function(t) {
body.className = ‘foo’;
t.expect(doc.getElementsByClassName(‘foo’)).toContain(body);
});
});
[/crayon]
The full list of matchers can be seen below (and they will also be described in the docs):
- toBe
- toEqual
- toBeNull
- toBeNan
- toBeDefined
- toBeUndefined
- toBeTruthy
- toBeFalsy
- toMatch
- toContain
- toBeLessThan
- toBeMoreThan
- toBeCloseTo
- toThrow
BDD UI tests
If you want to write more complex tests using chains of UI actions, those commands will be queued and executed in sequence. Let’s look at how this could be done. In the test case below, a simple input field is rendered together with a button. If the text is not a number, the field should receive an ‘invalid’ CSS class. The code below verifies the two cases, of valid vs invalid input. Note that we are using the not property to alter the meaning of the toContain expectation in the second spec.
[crayon striped=”false” lang=”javascript” nums=”false” toolbar=”false”]
describe(“My test suite”, function (t) {
function prepareBody(next) {
document.body.innerHTML = ‘
Input your age
‘ +
‘‘ +
‘‘;
// Simple click handler
t.$(‘.submit-button’).click(function(){
if (isNaN(parseInt(t.$(“.input-age”).val(), 10))){
t.$(“.input-age”).addClass(‘invalid’);
} else {
t.$(“.input-age”).removeClass(‘invalid’);
}
});
next();
}
t.it(‘Should find an “invalid” CSS class on the age input for invalid input’, function(t) {
t.chain(
prepareBody,
{ action : ‘type’, text : ‘a’, target : ‘.input-age’ },
{ action : ‘click’, target : ‘.submit-button’ },
function() {
t.expect(document.getElementsByClassName(‘input-age’)[0].className).toContain(‘invalid’);
}
)
});
t.it(‘Should not see the “invalid” CSS class on the age input for proper input’, function(t) {
t.chain(
prepareBody,
{ action : ‘type’, text : ’25’, target : ‘.input-age’ },
{ action : ‘click’, target : ‘.submit-button’ },
function() {
t.expect(document.getElementsByClassName(‘input-age’)[0].className).not.toContain(‘invalid’);
}
)
});
});
[/crayon]
In the Siesta UI, this is what we see:
Passed specs are collapsed by default, and if a spec fails it’s automatically rendered in expanded state so you can see the failed expectation easily.
By using the BDD syntax above, the test becomes very readable as each sub-section of the test is decorated with its purpose up front. But, since code readability is quite subjective by nature, you may or not not prefer this syntax over plain simple JS code in your tests.
What you do you think, will you be using this BDD syntax in your test suite after v1.2 is released? Let us know what’s on your mind!
Download the 1.2 beta-2 release here: