Behavior Driven Development with Jasmine

Once upon a time… there was just another ICT-project. My job was simple: be the test consultant and test along in the team. In the Scrum-team! I have a passion for test automation; so I wanted more than only my assignment.

Within a several weeks I got to know a lot of things: the product, my scrum-team, the IT-people, the business-people, the processes, the tools.

What I want

I heard about success-stories with “Specification by Example”. I read a lot about it and I’m sure this could be successful in Software development. “Specification by Example” is not a holy grail. It is nothing new (well… some part of it are… at least to me….). But you might recognize things from Behaviour Driven Development (BDD) or Acceptance Test Driven Development (ATDD). So I want to use the best practices and apply this in my project.

What I’ve seen in the project are too little tests. Sometimes poor unittests, little test-coverage, too technical Jasmine-tests. If I’d ask the quality of the product, the answer would be: “don’t know”.

So what I want was simple: increase the product quality, by increasing the testcoverage with automated tests that can be read by the business-people.

What I want, accomplished with tools – jBehave or Cucumber

I’ve seen SpecFlow before, with good results; I’ve seen FitNesse, also with good results. But in this Java-project FitNesse already has been prototyped. Unfortunately with little success.

I checked the tools Cucumber and jBehave. Both tools work quite nice. From a colleague I heard they would work with Cucumber. But experience in the team was present with jBehave. So we decided to start working with jBehave.

What the challenge was: time / project pressure

After one meeting I was convinced that project-pressure to deliver software for the business was more important than quality. There was a shared intention to increase the software quality. But not now and not with new tools.

What the alternative became – Jasmine-tests

Currently present in the project are Jasmine-tests. Jasmine is a framework to test javascript. It uses the jUnit-testframework. Problem with the created Jasmine-tests are: the tests are not very well structured and not very good readable. But Jasmine is a BDD-framework. To describe behavior of the system. So why not try this? Why not just do this?!

What was the first result – BDD with Jasmine

After some sprints I created some tests. Not the implementation of the real test, but the expected behavior of how the system should work. An example of my first Jasmine-test:

describe(“View Beneficiary Template”) {
it(“is by default loaded with all open templates a user is authorized to”) {
}
it(“will show a message when no beneficiary templates could be found”) {
}
}

The actual test (the code in the “it”) was written by developers. And the test became more behavior driven.

What was another problem

Jasmine-tests are perfectly applicable to test Javascript of your system. But it’s not possible to test your system components or system functionality that is not part of the Javascript. So some tests were left empty and only used as a framework. But the team was (and still is) positive with this approach. So we decided to push other functional tests down to the technical layer. For this: unittests (jUnit) was a solution. References to unittests were added, where it’s not possible to test the functionality with the Jasmine-test.

What the future will be (so I hope) – BDD with executable specification

BDD is very well started. Tests (or test descriptions) are written with a more functional perspective; the actual tests are written by the developers. A best practice in Test Automation.

I wonder though if it will be enough to use it as executable specification. Also some other improvements have to be made:

• Can the Jasmine tests be used as executable specification?
• Will it be used as executable specification?
• The business has to write the Jasmine tests:
  Will they do this…
• What about the Jasmine tests when project is finished?
  The application (and tests) have to be maintained by the organization. How will future development of the product be done? How will small changes be implemented?

A lot of questions; a lot of possible improvements. But changes are made with small steps. And this is a good start. It is important to keep up the good work; to keep moving the small steps to the improvement of Software Development and Application Lifecycle Management!

And the game continues…