Wallaby.js - a small beast with a great future
I uncover the typewriter infrequently, but today there is a reason.
JavaScript tests are written by many, some write many tests. There are several popular test frameworks, such as Jasmine, Mocha, QUnit, as well as tools for automatically running tests. Some of them are even integrated into some code editors. For example, Karma runner and Mocha are perfectly integrated by my colleagues in WebStorm. In short, there are different ways to run tests automatically and get results within one or a few seconds. However, time depends on the number and nature of tests.
How we use our javascript tests
And everything would be fine, but the average size of the JavaScript code in projects is growing . The code is getting bigger, the tests are getting bigger, and the execution takes longer. And now comes the moment, and sooner or later it always comes when it becomes somewhat uncomfortable when we run hundreds or thousands of tests while editing the code. No, we certainly set up CI build, where all the tests are run, we sometimes look at the generated reports on the test coverage, use cloud or home solutions to run the tests in different browsers and other Internet exploders. But all this does not really help where we spend the best years of our life - namely, in writing the bulk of JavaScript code.
')
Every good test is beneficial, and even not very good tests in JavaScript perform, at a minimum, the role of the compiler, because they swear at all the inaccessible static analysis of the jambs in the way of their execution. The trouble is that as a person does not fully use the capabilities of his brain, we also inefficiently use the great potential of our tests . They could not gather dust on the build server, but run each time the key is pressed, immediately provide useful information, instantly highlight problems in the code that we write at this particular moment. Otherwise, it turns out that we have a sports car, which we plant only once a day, and even then to take the child to school.
It's time to release the beast from the cage!
The beast is called wallaby, it is such a marsupial animal smaller than a kangaroo in size, living on the continent, where for many years I have been inhabited (and kangaroo).
So, get acquainted: wallaby.js is a smart tool to run tests automatically, which I wrote and released just a week ago (of course, on Australia’s day). Despite the age of one week, wallaby has already aroused considerable interest in the JavaScript community of developers and is even already used in production. It is based on only three simple principles.
The first is a permanent test coverage . Speaking of coverage, I do not mean boring numbers and meticulous types of coverage. When writing a new or editing an existing function, I don’t care 81% or 92% is my coverage. When I write code, I don’t care about it every second. All I want to see is unobtrusive and not very distracting indicators right where I write the code.
The second. If I edit some kind of test or code that I know is covered by one or even several tests, then why can't my tool know about this and use this knowledge wisely? All I need is that when I make a change to the code, only what is affected by my change is done - no more and no less.
Third. If my code change requires running several test files, and my test files are independent (and they must be independent), I want the full potential of my system to be used and the tests run in parallel .
These three simple principles, as well as deep integration with the code editor (currently supported are WebStorm, PhpStorm, IntelliJ IDEA Ultimate, PyCharm Professional, RubyMine , Visual Studio support in the process - a screenshot in the tweet below), support for popular test frameworks ( Jasmine, Mocha , QUnit ), showing error messages and console.log messages right where they occur, screenshots of test execution are only part of what wallaby.js can do.
Now the tests can be used much more efficiently, returning to the analogy with a racing car - we install the free beta version of wallaby and gas to the floor!
JavaScript tests are written by many, some write many tests. There are several popular test frameworks, such as Jasmine, Mocha, QUnit, as well as tools for automatically running tests. Some of them are even integrated into some code editors. For example, Karma runner and Mocha are perfectly integrated by my colleagues in WebStorm. In short, there are different ways to run tests automatically and get results within one or a few seconds. However, time depends on the number and nature of tests.
How we use our javascript tests
And everything would be fine, but the average size of the JavaScript code in projects is growing . The code is getting bigger, the tests are getting bigger, and the execution takes longer. And now comes the moment, and sooner or later it always comes when it becomes somewhat uncomfortable when we run hundreds or thousands of tests while editing the code. No, we certainly set up CI build, where all the tests are run, we sometimes look at the generated reports on the test coverage, use cloud or home solutions to run the tests in different browsers and other Internet exploders. But all this does not really help where we spend the best years of our life - namely, in writing the bulk of JavaScript code.
')
Every good test is beneficial, and even not very good tests in JavaScript perform, at a minimum, the role of the compiler, because they swear at all the inaccessible static analysis of the jambs in the way of their execution. The trouble is that as a person does not fully use the capabilities of his brain, we also inefficiently use the great potential of our tests . They could not gather dust on the build server, but run each time the key is pressed, immediately provide useful information, instantly highlight problems in the code that we write at this particular moment. Otherwise, it turns out that we have a sports car, which we plant only once a day, and even then to take the child to school.
It's time to release the beast from the cage!
The beast is called wallaby, it is such a marsupial animal smaller than a kangaroo in size, living on the continent, where for many years I have been inhabited (and kangaroo).
So, get acquainted: wallaby.js is a smart tool to run tests automatically, which I wrote and released just a week ago (of course, on Australia’s day). Despite the age of one week, wallaby has already aroused considerable interest in the JavaScript community of developers and is even already used in production. It is based on only three simple principles.
The first is a permanent test coverage . Speaking of coverage, I do not mean boring numbers and meticulous types of coverage. When writing a new or editing an existing function, I don’t care 81% or 92% is my coverage. When I write code, I don’t care about it every second. All I want to see is unobtrusive and not very distracting indicators right where I write the code.
The second. If I edit some kind of test or code that I know is covered by one or even several tests, then why can't my tool know about this and use this knowledge wisely? All I need is that when I make a change to the code, only what is affected by my change is done - no more and no less.
Third. If my code change requires running several test files, and my test files are independent (and they must be independent), I want the full potential of my system to be used and the tests run in parallel .
These three simple principles, as well as deep integration with the code editor (currently supported are WebStorm, PhpStorm, IntelliJ IDEA Ultimate, PyCharm Professional, RubyMine , Visual Studio support in the process - a screenshot in the tweet below), support for popular test frameworks ( Jasmine, Mocha , QUnit ), showing error messages and console.log messages right where they occur, screenshots of test execution are only part of what wallaby.js can do.
hey @VisualStudio devs, first teaser on what’s coming to you with http://t.co/93Ngi23tij / cc @shanselman @mkristensen pic.twitter.com/IOaCdG0LSp
- Artem Govorov (@ArtemGovorov) January 29, 2015Now the tests can be used much more efficiently, returning to the analogy with a racing car - we install the free beta version of wallaby and gas to the floor!
Source: https://habr.com/ru/post/249473/
All Articles