QUnit: JS Unit Test framework

QUnit is a powerful, easy-to-use JavaScript unit test suite. It’s used by the jQuery, jQuery UI and jQuery Mobile projects and is capable of testing any generic JavaScript code, including itself!
QUnit: A JavaScript Unit Testing framework

This is used by the jQuery projects, so probably worth a look. Javascript has found new niches, with all the extensibility available now to develop effective web front-ends in a more secure and efficient manner. Javascript detractors have long predicted demise of Javascript, but that’s a way off yet and perhaps now irrelevant, given the previous accusation centred around it’s limitations.

(U)n(I)t Testing

I used to think companies who advertised for unit testers, had developers who couldn’t be bothered with them, and managed to convince someone it was a testers job anyway. Fast forward, and now it seems the lines are blurring.

I’m recently seeing adoption of a more unit testing style of developing test automation scripts.  For web application testing, even better if those tests can be run in headless browser.  So instead of simply thinking about the end to end test, also think about how to break it down for reusable components.  Tester and Developer roles are getting irrevocably closer together.

Testers can design these tests, before there is actual code to test … its called BDD 😉 And given the DSL/DSM  direction of development, it seems testers will be more future-proof than developers.



“I am struggling to do this”, or “I need some help” or “I’ve finished, give me something else” are not common phrases to hear on projects. It’s the old ways again, now Agile has lost it’s grip as people more freely slate it. Agile was not a hard enough kick, but Lean development certainly is.  Lean development is not disconnected with Agile, as Agile takes some principle from lean (manufacturing).  Scrum was first applied in manufacturing to streamline the product quality process. Apply them to the more people-sensitive world of IT, and you have a lot of psychology to learn quickly to overcome the most common point of failure for any project – people. Or rather the understanding and communication.

It doesn’t take much to make someone feel appreciated in their efforts. It should quickly be established that the important part is the journey, not the destination. Struggles overcome, or mistakes learnt from as advantages for the project, and knowledge for future projects. It is all very well applying process, but without the team selling up to same ideal and following it, it’s a fruitless exercise where the only surprise will be how the project will fail. It make still work, it may still even make money, but in the shallow world of IT and Sales, website looks that kill, can easily mask a hideous mess underneath.

TDD is a very clean approach to programming – a little too simple for business requirements though, but BDD covers other sides in more detail, aimed at entire project rather than just development. Asides fighting a more established acronym (Body Dysmorphic Disorder), BDD works on sound basis that tests should directly correlate to requirements. And that being the case, then a further link in the chain could be added. The User Story.

What BDD and TDD share in common though is a very structured approach to development, with adherently more administration and maintenance. This is why many developers do not like this approach – it forces them to develop in a structured (and auditable) fashion. BDD can feel like a roller-coaster, but run well extremely efficient. Apply Kanban to the project management (Scrum would struggle to keep up). but requirements and code will merge into one in the future. For now BDD can forge a path, given it’s ideal suited for DSM/DSL approach to development. I go into depth with these in other posts, but just imagine the next steps in programming where what we consider as programs now are rapidly becoming components – the whole nature of the evolution of programming.

The BDD tools available use DSL approach to generates test script framework from entered User Stories/Scenarios. These vary a little from traditional format as they can also include such things as tables of data, and more detailed pre-requisites information. It is not for the faint-hearted, as even those with a lot of experience with requirements will have to work hard to make sure these User Stories hang together. Indeed, the process can quickly highlight requirements that may contradict each other, or cause technical issues. The method is within the area of DSL, the concept of generating code from directly from requirements written in real language.

The tools (such as Cucumber and Specflow) got part way down this path, generating a good test script from the entered User story. Cucumber and Specflow use the Gherkin language for User stories. Any amendments will update the test automatically, but it won’t update the code! This is where developers have to be particularly aware.

Another good side of adopting this approach is it quickly identifies project “wallflowers”. It is uncomfortable truth that companies do carry dead-weight. I am not talking about lack of skills – these can be gained in right environment with team members who can mentor and guide. I am talking about attitude. Modern development approaches are supposed to inspire, as well as help deliver projects well. The “wallflowers” are ones who simply go through the motions in the workplace, and have little desire to change their workload. There are places for these people, but not in modern development.