TiShadow for Titanium Development - Part 4

In Part 3 of this series on TiShadow, we covered TiShadow’s support for native modules and appified apps. In this post we will look at TiShadow’s support for Behavior-driven Development (BDD) using Jasmine and some debugging techniques.

Behavior-driven Development with Jasmine

TiShadow embeds the Jasmine BDD test library. It is recommended that you visit Jasmine’s site to understand all of the capabilities it offers – it’s documentation is clear and succinct.

That being said, I will give an overview of BDD and Jasmine so that we can move quickly into applying it to test Titanium applications with TiShadow. You may jump to the Getting Started with Jasmine Using* TiShadow* section if you don’t need or want to go through this background material.

Behavior-driven Development (BDD)

BDD is a software development process that was an outgrowth of the earlier developed Test Driven Design (TDD) methodology. BDD is a specialized version of TDD which focuses on the desired behavior of software components.

Behavior-driven development is an “outside-in” methodology. It starts at the outside by identifying business outcomes, and then drills down into the feature set that will achieve those outcomes. Each feature is captured as a “story”, which defines the scope of the feature along with its acceptance criteria.

BDD tests are specified with a semi-formal syntax that can be understood by all technical as well as non-technical members of the development team. That is, it is a structured syntax that reads somewhat like natural language rather than a programming language.

Jasmine

Jasmine is a particular implementation of BDD for testing Javascript code. The essential concepts that what we are concerned with in Jasmine are test suites and tests. Jasmine refers to tests as specs.

Jasmine’s describe function is used to encapsulate a test suite, and takes the form:

<strong>describe</strong>(<test_suite_name>, function() {  
    < spec tests >
});

A test suite name is provided to collect together and identify a set of related tests, and the spec tests are encapsulated within the passed function.

Each spec test contains one or more assertions (called expectations in Jasmine) about the state of the application at the end of running the test spec. If all of the expectations pass (evaluate to true) then the overall test spec passes, otherwise it fails.

A basic Jasmine test spec function within the test suite takes the form:

<strong>it</strong>(<test_spec_name>, function() {  
    < code interacting with software under test >
    <strong>expect</strong>(<expression_1>).<strong>toBe</strong>(<boolean_value>);
    <strong>expect</strong>(<expression_2>).<strong>toBe</strong>(<numeric_value>);
});```

A test spec name is provided to identify the test result, and assertions in the form of *expect* statements test for the expected software state at the end of the test spec.

Within a test suite, Jasmine offers a pair of methods to avoid having to repeat boilerplate set-up and tear-down code for each and every test. These methods have the names *beforeEach* and *afterEach*. As suggested by their names, the *beforeEach*() method is executed before each test spec is executed and *afterEach*() is executed just after each test spec is executed.

Putting all of this together, a basic *spec file* containing a test suite would take the form:

describe(, function() {
beforeEach(function() { < code executed before each spec test > }); afterEach(function() { < code executed after each spec test > }); it(, function() { < code interacting with software under test > expect().toBe(); }); it(, function() { < code interacting with software under test > expect().toBe(); }); });```

There is plenty more to what Jasmine has to offer than has been described here. We will touch on the use of Jasmine spies when we discuss the use of Jasmine within TiShadow.

Getting Started with Jasmine Using* TiShadow*

shadow<em>test</em>countFor this tutorial we will be using an updated version of the ShadowTest application introduced in the previous post from this series. The application provides a simple counter with a pair of buttons for incrementing and decrementing the count. The counter clamps at 0 so that it will not go negative.

We will explore the use of Jasmine within TiShadow for testing the proper operation of the counter function of this application.

The view specification has a counter label with ID count, and two buttons with IDs increment and decrement. The controller code has a counter named vars.value and a pair of click event handlers, increment and * decrement* corresponding to each of the buttons.

It is handy to use the TiShadow REPL to inspect the application’s controller and see what we can currently access from our Jasmine test code. **

Make sure that the TiShadow server is running and that you start from the project’s top directory. Type tishadow repl at the command line and you will enter the command line environment for interacting with TiShadow.

As was previously mentioned, the Jasmine library is already built into TiShadow so all TiShadow apps are prepared to execute Jasmine based tests. The test suite files must be placed in the spec directory which is located in the project’s root directory. Each test file must end in _spec.js to be picked up by TiShadow when the Jasmine tests are executed. The test files are not embedded into an application when generating a standard development or production build of the application.

Summary

In this post we  explored TiShadow’s support for Jasmine based BDD testing and some debugging techniques.

Resources

joliva

0

Subscribe to Oliva Labs Blog

Get the latest posts delivered right to your inbox.

or subscribe via RSS with Feedly!