Tag: Unit Testing

React allows you to create components that will render UI for your application. If your UI is of any complexity, you’ll likely want to test that it functions correctly and allows for future refactors. There are numerous ways to do this. One way that you might appreciate is using jsdom, an in-JavaScript implementation of the DOM.

Testing React Components has been easier and more enjoyable than any previous UI unit testing I’ve done in the past. Components that have interesting things happen in lifecycle methods have a little more setup to get tested. Components that use the componentWillReceiveProps method are in this category.

Sinon provides spies, stubs, and mocks. They’re all useful as fakes in tests. They come with essential differences for what they’re helpful in doing and how they work.

Rack apps are generally straightforward to test because of their very basic public interface. But where do we put specific things, in this case, a cookie for the request, on that env argument it takes? Here’s one way.

As soon as we begin to write a test for our code, it is natural for us to think that we are doing a good thing, and often, we are. Yet, I believe there are times that we’re writing tests when we’re hurting more than helping — and, of course, this is not on purpose. To clarify, I’m an advocate for testing in general, and this is a short thought on how to make it better.

BusterJs is a still-in-beta library that allows for testing your Javascript. It’s got a wealth of cool features. The browser capturing is awesome for running your Javascript directly in the browsers you choose from one runner. You can also execute within Node. In short, it rocks. But, how to get this rockin’ with your project, specifically your AMD RequireJs with BackboneJs combo project is the lock that must be opened before daily buster love can be had.

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 environment.

Tools: We’ll also introduce you to in-house-developed tooling for creating unit tests and running them. This tooling provides an all-Xquery method of creating test functions, annotating them as such so they’re runnable in the test runner, isolating certain modules to test, and viewing clear test results.

With a few principles, skills, and tools for unit testing, you can go forward with increased confidence that the Xquery code you write on MarkLogic is more awesome than ever.