Building the Responsive Radio Nav (Using BDD)

The aim was to have a more up to date navigation bar which is fully responsive across all platforms. We took the Behaviour Driven Development (BDD) approach which involved us writing tests & defining the behaviour of our nav first. Before doing that we needed to come up with a way this nav would work.

 

Architecture & Idea

Rather than the old nav which showed a dropdown on hover we decided on pushing the page down to show some content (see above). The nav itself extends revealing individual sections such as “Stations”, “Programmes” and “Categories”. The content shown can be interactive; for example the “Programmes” tab allows you to search with results changing as you type. These sections are called Panels, and are inside a container which moves up and down known as the Drawer. There is only ever 1 Drawer but we can have as many panels as we like. The panels are Javascript objects (extending the Panel object) which reference HTML elements containing markup. This allows us to extend the nav and change panel content very easily without touching the core functionality, if we wish to bring in a new Panel we can populate a Panel instance with content (written in HTML) and add that to the Drawer. In this example we create a new (stations) panel object, passing in the name of the panel, reference to the button (its control) and the element which hold the panel content.

The radionav was broken down into separate modules (using RequireJS) which gave us a Model, View, Controller structure. The View would manipulate the DOM, our Models would gather data (for our Programmes panel) and the Controller would handle everything inbetween such as user actions.

Building in a BDD fashion

Testing the Javascript, TDD First

For testing we started with modules that weren’t directly affecting the layout; for example modules which just handled collecting data for search results (Models). The tests treat these modules as a black box; they input a query then get data returned. The implementation right now is not important, just that it handles every edge case and weird condition we could come up with. Jasmine is a Javascript testing framework, and was used to run several tests over these modules (inserting special characters, numbers, faking 404’s, mocking ajax requests. etc). All tests failed as we had no implementation yet; over 30 tests were written overall.

Testing Behaviour

We then moved to the visual behaviour of the radio nav itself; including animation, colours changing, links working properly and content showing on certain screen sizes. Each of these scenarios were written in a language known as Gherkin. Gherkin can be understood by cucumber which in turn talks to Capybara, a tool which simulates real world interaction. These tests are then ran in a browser automatically and therefore becomes very useful when building anything that’s responsive as we can resize the browser, check what appears, resize again, repeat..

The Good

Our build process involves using Hudson to automatically push our changes to a test server. Adding the Jasmine tests to run on each build meant we could spot any issues before our code is deployed. We achieved this using PhantomJS: a headless browser engine which can execute Javascript code in the terminal and output errors. The Cucumber tests were ran manually but often as we could not easily have these run on different servers or environments automatically

The advantage became clear when we changed how we wanted certain modules to work before writing up any code, had we changed our minds later the process would have taken longer. You are also clarifying your requirements from the beginning with everyone, this should mean less confusion across the board when features (and their usability) are brought to light. Stakeholders being able to read and understand the requirements (scenarios) you wrote down for each feature provides an advantage too.

The Bad

The BDD process certainly takes more time, you need to think about investing time to write tests, to consult with others when sketching out scenarios on how your product will work and learning new frameworks/languages. There’s no denying this adds more overhead and its certainly not something which will run smoothly amongst the team overnight.

Libraries and Techniques

when.js

We have our models which asynchronously go of an get data for search results in the programme panel. Instead of using typical JS callbacks we use promises. Promises are very powerful and represent the eventual outcome of an asynchronous action, they’re also chainable. You can read more about the Promises/A+ spec here

EventEmitter & RequireJS

By calling events rather than functions directly means we can hook multiple functions to a particular event. Our section of code that handles the view fires off events when actions happen by the user (I.E clicking on the search box, typing in a query etc). The event fires and the view sits and waits for data to come back. By separating logic into modules we can swap out how our implementation but keep the view the same.
These modules are put together with RequireJS.

CSS(3) Transitions

Well it seems we’ve reached a point where we can do CSS transition and have them degrade gracefully; browsers not supporting these just open and close. The opening and closing of the drawer is a CSS transition. This brings us a nice advantage of having the animations being handled directly by the browser; It should give us a much smoother transition. Our JS code can listen on the transtionEnd event to know when the drawer has finished opening/closing.