Wallaby.js - unleash the full power of your tests

Many JavaScript developers understand the importance of writing tests and do use them. There are a few testing frameworks and test runners available in JavaScript land. Some of them are even nicely integrated into some code editors. For example, there’s a nice integration of Karma runner in WebStorm. There are some automated testing workflows, where you can enjoy your tests’ feedback after a few seconds or so (depending on the size of your codebase).

How we use our JavaScript tests

The issue is that an average JavaScript codebase size is growing. We write and test more JavaScript code, but at the same time we want to run our tests faster, because faster feedback means better control over the growing codebase. But when we have hundreds and thousands of tests, even relatively fast ones, it becomes quite a burden to run them frequently, as we write our code. Yes, we’re still running them all as a part of our CI build, we’re inspecting generated coverage reports, we’re using various cloud and on-premises solutions to run our JavaScript tests in different browsers and on different devices. But it doesn’t help us where we’re spending the most of our time - when we are writing the bulk of our application logic.

Each good test we write adds some value, and, in JavaScript, tests are more than just recorded assumptions, But we are not using our tests full potential. They can do much better job than they are doing now. They can run on every key stroke and provide some helpful feedback, immediately highlight found issues in the code that you’re writing. But when we run them all and sequentially - we can’t have it. It’s like having a sports car and only driving it once a day and within a school zone speed limits.

Unleash the full power of your tests

In wallaby.js, I have decided to tackle these issues and build an intelligent test runner, that allows you to exploit the full power of your tests.

First, code coverage is not an option - it’s the must have. But that’s not those boring numbers of coverage percentage I am talking about. When I am writing my code and tests, I don’t care whether I have 89% or 91% percent of my code covered. I don’t want to know if it’s a statement coverage or a condition coverage, when I’m typing my function code. I just want to see coverage indicators right when and where I’m editing my code and without too much distraction.

Second, if I am editing a single test or a function that I know is only covered by a few tests, why my test runner can’t know about it and use the knowledge? I just want it to run everything that depends on my change, everything that may change its behaviour after my change - no more, no less.

Third, if my change requires a lot of tests to be executed and my test files are independent (and they should be), I want to use the full power of my machine and run tests in parallel.

Wallaby.js design is based on the simple principles listed above and is focused on improving your everyday and every minute code writing experience. Inline error/console messages and expectation failures, where and when they occur, test execution screenshots, context actions - these are just few things wallaby.js provides to make you more productive.

With wallaby.js, there’s no longer a wall between you and the full power of your tests. Go ahead, install wallaby.js and release the beast from its cage.