Book Image

Test-Driven JavaScript Development

By : Ravi Kumar Gupta
Book Image

Test-Driven JavaScript Development

By: Ravi Kumar Gupta

Overview of this book

Initially, all processing used to happen on the server-side and simple output was the response to web browsers. Nowadays, there are so many JavaScript frameworks and libraries created that help readers to create charts, animations, simulations, and so on. By the time a project finishes or reaches a stable state, so much JavaScript code has already been written that changing and maintaining it further is tedious. Here comes the importance of automated testing and more specifically, developing all that code in a test-driven environment. Test-driven development is a methodology that makes testing the central part of the design process – before writing code developers decide upon the conditions that code must meet to pass a test. The end goal is to help the readers understand the importance and process of using TDD as a part of development. This book starts with the details about test-driven development, its importance, need, and benefits. Later the book introduces popular tools and frameworks like YUI, Karma, QUnit, DalekJS, JsUnit and goes on to utilize Jasmine, Mocha, Karma for advanced concepts like feature detection, server-side testing, and patterns. We are going to understand, write, and run tests, and further debug our programs. The book concludes with best practices in JavaScript testing. By the end of the book, the readers will know why they should test, how to do it most efficiently, and will have a number of versatile tests (and methods for devising new tests) to get to work immediately.
Table of Contents (16 chapters)
Test-Driven JavaScript Development
Credits
About the Authors
About the Reviewers
www.PacktPub.com
Preface
Index

Creating a custom matcher


In Chapter 2, Testing Concepts, we read that unit tests act as documentation to the project. In order for them to be descriptive, success and failure messages of tests should be very clear. But, sometimes, the default matchers as explained previously, are not sufficient or leave us with unexpected, unclear messages when fail or pass. For example, our expectation is:

expect(employee.salary).toEqual(9000);

This results in failure because the actual salary was 4,000.

Expected 1000 to equal 9000.

By looking at the message, you cannot detect what the context was. How about if it was something like: "Expected salary of employee was 9000 but found to be 4000". This message gives us an idea from the message itself that the salary calculated must be wrong. To overcome this, Jasmine supports a creation of custom matchers.

Suppose we have a large number of employees in the context of a project and we need to check if an employee has marked his/her attendance daily. Our development...