RockyCode

As more application logic gets pushed into the browser for client-heavy apps, the need for javascript testing increases. Lately, I've been doing some Jasmine unit testing of an application that uses RequireJS. Here are some general pointers and potential pitfalls to watch for.

Unit testing is a required part of a healthy software development lifecycle and a balanced breakfast. But test-driven development is a rockin' part of an *awesome* development lifecycle. What's the difference? If you don't test-drive the dev of your MarkLogic XQuery, you may never come back to test again. Test-driven XQuery development will ease your headaches, put you into the plush seat of a developer with confidence, and rocket you down the road to making all your wildest dreams come true. Kachow!

Unit testing is a required part of a healthy software development lifecycle. Business logic in MarkLogic Xquery needs the same insurance of superb testing as any other language.

Principles: Come learn the motivation for unit testing and how test-driven development can increase your productivity writing solid Xquery code in an Agile-coding environment.

Skills: We'll code Xquery examples to learn general skills including the TDD workflow, how to isolate your code for unit testability, and how to test one thing at a time. In each case, we'll address how to apply these skills specifically to development in the MarkLogic ...

EasyMock is a great tool for separating external dependencies from unit tests. There is a learning curve to learning the mock method of testing, and unfortunately, EasyMock does not give very good prompts when you do something wrong. The exception messages are actually quite cryptic. This article is meant to be a crude mapping of exception output and the behavior that might have caused it. At least, this is a log of many of my experiences with EasyMock and how I usually get into the messes I do. It is quite possible that the same exception output could be had ...

For unit testing purposes, I often want to set field values in objects so that I can setup for the test conditions. One of most annoying things about testing is the urge to change code design for just the sake of testing -- especially if it's in a way that is considered less safe, like exposing elements or lessening accessibility. (This is not to say that trying to test code can reveal certain code smells and prompt refactoring). I, myself, have a number of setter methods with this comment prepended: "// for test only comments". Stinkers! Well, sometimes enough becomes enough ...

First-class objects are the norm in the code that I usually write and edit, but every now and then I run across a method with a primitive parameter. I use EasyMock a lot in testing, and need to find these methods by reflection, this is how it's done...