Tutorials: VS Code tutorial

First you need to install Wallaby.js extension for VS Code, if you haven’t already done so.

For this tutorial we will use our sample calculator repository. You can clone it to try locally:

git clone https://github.com/wallabyjs/calculator-sample.git

Once you have the source code locally, open the project folder in VS Code.

There you will find a simple calculator project with a Wallaby configuration file. The Wallaby configuration file is a simple JavaScript file in your project root folder with just a couple of mandatory settings. The configuration file includes a list of files and tests for your application as well as some settings for various technologies that you may be using to build your project, such as Webpack or Browserify configuration Babel/CoffeeScript/TypeScript compiler options, etc.

Wallaby supports lots of technologies and scenarios, we have a collection of sample projects with configuration files for different tools, frameworks and languages, such as Webpack, Browserify, ES6 and ES7 via Babel, TypeScript and CoffeeScript, React, Angular, Vue, Node.js and io.js, etc.

Note that the simple calculator configuration used in this tutorial is using Google Chrome (headless) to run tests. You may also use Node.js, Electron, or PhantomJs as environments to run your tests.

First steps

Configuring Wallaby

Wallaby for VS Code needs to know what configuration is required to run your tests. If a technology is detected that is supported by automatic configuration, then Wallaby will start automatically without any configuration. If you want to use a configuration file or have a mono-repo and only want to run for one project, you may select a different configuration using the Wallaby.js: Select Configuration command from the editor Command Palette.

If your project does not support automatic configuration then Wallaby will automatically search for a configuration file in your project root and will automatically select it, valid names are: wallaby.js, wallaby.conf.js, .wallaby.js, .wallaby.conf.js, wallaby.json, and .wallaby.json. If you use multiple configuration files, use different naming convention, or have the config file not in the root folder, you may select the config file using the Wallaby.js: Select Configuration command from the editor Command Palette.

Wallaby.js Command Palette

As you probably know, you may press Ctrl/Cmd + Shift + P in VS Code to get the editor Command Palette in case if you’ve forgotten some shortcuts or just like invoking commands this way. There you may search for Wallaby to get the list of available commands you can execute.

For convenience, Wallaby adds its own Command Palette to the editor that you may display by pressing Ctrl/Cmd + Shift + =. It is a fast and easy way to quickly get to Wallaby commands.

Now let’s have some fun.

Let’s try starting Wallaby. To do that you need to run the Wallaby Start command. You may do it by using the Ctrl/Cmd + Shift + R, R shortcut, or using the Wallaby Command Palette.

To stop Wallaby, you may use the Stop command.

Wallaby in action

Once you have started Wallaby, at the bottom right corner of the editor you’ll see Wallaby status indicator. It’s job is pretty simple: when it displays a spinner - your tests are running, when it shows a cross - you have some failing tests, when it shows a tick - all of your tests are passing. It also shows the number of failing or passing tests, and you may also use the indicator to show ‘Wallaby.js Tests’ Output Channel by clicking it.

Now, let’s open the sample calculator project spec (test/calculatorSpec.js).

When Wallaby is running, you will see the code coverage in opened source files (specified in Wallaby configuration file). As you can see, there are various colored squares displayed for each line of your source code.

Try jumping to any of the passing tests and break it, for example try changing the 2 plus 2 expectation result to 5 in the should add numbers test, or try breaking the code covered by the test. Right after the change Wallaby automatically runs your tests and displays the result in status bar.

The code coverage and messages are automatically updated, right as you type.

Also, try editing some console.log arguments or just console.log any object you like.

This is a great way to quickly inspect any objects without having to leave your editor, without switching to any other console. Think how cool it is - your code editor is your console with all the required context.

We recommend reading about some more powerful ways to log things and measure code performance with wallaby.js.

Watch expressions in action

Watch performance in action

Coverage indicators

Let’s have a look at the editor gutter where you may see some indicators. Here is what these coverage indicators mean:

  • Gray squares mean that the source line is not covered by any of your tests.
  • Green squares mean that the source line is covered by at least one of your tests.
  • Yellow squares mean that the source line is only partially covered by some of your tests.
  • Red squares mean that the source line is the source of an error or failed expectation, or is in the stack of an error.
  • Pink squares mean that the source line is on the execution path of a failing test.

Failing tests

The ‘Wallaby.js Tests’ Output Channel displays all tests that are currently failing along with the error stacks and registered console.log calls. Some of the information displayed includes hyperlinks so that you can easily navigate to different places, for example to the exact error line, or a line where something is logged to console. To quickly focus the panel you may use the Show Failing Tests wallaby command (Ctrl/Cmd + Shift + R, T).

When a test error contains expected and actual properties, the ‘Wallaby Tests’ output channel, as well as the error hover tip, displays compact diff view and can display side-by-side diff view. This allows you to quickly debug failing equality assertions and snapshots.

Diff views

Value Explorer

Value Explorer integrates with Wallaby’s existing variable and expression output mechanisms (console.log, live comments, identifier expressions, and the Show Value command) to display values in an easy-to-navigate, real-time tree view. The tree can be expanded to any depth and can copy paths/values to the clipboard.

Value Explorer in action

Time Travel Debugger

Wallaby’s Time Travel Debugger allows you to move forward and backwards through your code to understand the conditions that led to a specific bug. The Time Travel Debugger accelerates your edit, compile and debug loop by allowing you to jump to a specific line of code, view runtime values, edit-and-continue and step into, over and out of your code.

Time Travel Debugger in action

Once Wallaby has started, the time-travel debugger is available at any time. The debugger can be started from any of your project’s tests. Navigate to the line of code where your test starts and run the command, Wallaby.js: Debug Test (Shift + F5).

In addition to being able to start the debugger on the line of code where your test starts, you may also start the debugger on any line of your code that is executed by your tests. When you start the debugger from a line other than the start of your test, the debugger will start and automatically progress to that line. If you start the debugger from a line of code that is covered by multiple tests, you will be prompted to select which test you want to debug.

Test focusing

Sometimes when writing or debugging a test, set of tests or test file for a particular feature, you may need to see code coverage and output only for this specific test , set of tests or test file. Wallaby fully supports testing frameworks test focusing functions such as it.only, as well as special comments to focus/skip specific test files. In addition to this, Wallaby also supports test focusing via the Toggle Test Filter command which allows you to see coverage indicators, console messages, live comments messages and errors messages only for a specific test.

Commands

To help you writing/navigating your code and tests more efficiently, Wallaby provides a few commands. You may see the full list in the Wallaby.js Command Palette (Ctrl/Cmd + Shift + =).

These commands include:

  • Show Line Tests: displays the line related test data. The command allows you to quickly view all tests (both failing and passing) that cover the current line of code, navigate to test and code errors, view console messages related to some specific test or some source code line.
  • Jump to Failing Test: allows quick navigation to the failing test from any ‘pink’ context (the failing test execution path).
  • Jump to Error Source: allows quick navigation to the source of the test error from any ‘pink’ context (failing test execution path).
  • Toggle Uncovered Code Regions: displays/hides uncovered regions for an opened file. The command is very useful for ‘yellow’ lines to display what is exactly not covered in the line. Highlighted markers will automatically disappear when you start editing your code or if you press Esc.

  • Run Line Tests: the command is pretty simple, it just runs a single test (if invoked from within the test) or all related tests (if invoked within some source code covered by the tests).
  • Run Lile Tests: the command runs all tests within the test file it is invoked in, or all tests in all the test files that cover the source file that the command is invoked within.
  • Run Project Tests: the command runs all tests in your project.
  • Update Project Snapshots: the command updates all Jest snapshots in your project.
  • Update File Snapshots: the command updates all Jest snapshots in the current (focused) file, or all snapshots in all the test files that cover the source file that the action is invoked within.
  • Update Test Snapshots: the command updates snapshots of a single test (if invoked from within the test) or all snapshots in all related tests (if invoked within some source code covered by the tests).
  • Toggle Test Filter: sets/clears the test filter. When the test filter is set, the command shows coverage indicators, console messages, live comments messages and errors messages only for the selected test. When the filter is cleared, the command shows coverage indicators, console messages, live comments messages and errors messages for all tests. The Test Filter may also be cleared by pressing Shift+Esc or by executing the Reset Test Filter command.
  • Show Last Screenshot: the command displays the screenshot for the last run test (Important note: this feature works only when running your tests using Chrome and PhantomJs).
  • Make Current Session Run on Any Change: the command makes your current Wallaby session start a test run when code is changed in your editor or when code is saved on disk.
  • Make Current Session Run Only on Save: the command makes your current Wallaby session start a test run ONLY when code is saved on disk.
  • Toggle Current Session Run Mode (Any Change/On Save): the command toggles between Make Current Session Run on Any Change and Make Current Session Run Only on Save.

Changing Wallaby’s Start Mode

By default, Wallaby will try to automatically start when you open your folder or workspace if it was running when the VS Code window was closed. If you never started Wallaby, then it will never try to run for your project. If Wallaby was started (either automatically or using a command) but test results were never returned, then Wallaby will not try and start automatically when the folder or workspace is re-opened.

After starting Wallaby, if you do not want Wallaby to start automatically when your folder or workspace is re-opened, run the Stop command.

If you never want Wallaby to start automatically, then you can disable this behavior entirely. The option may be configured globally as a User preference and may also be overriden as a Workspace preference. To change the setting, use VS Code’s Preferences: Open Settings (UI) command and tick/untick the Start Automatically checkbox:

Changing icon colors

Coverage indicator colors may be changed in VS Code user settings (settings.json file). You may find the example with the default colors below.

{
    ...

    "wallaby.colors": {
        "covered": "#62b455",
        "errorPath": "#ffa0a0",
        "errorSource": "#fe536a",
        "notCovered": "#cccccc",
        "partiallyCovered": "#d2a032"
    }
}

Windows Subsystem for Linux (WSL)

For Microsoft Windows environments, Wallaby can be configured to run using WSL. This configuration option is only available in your VS Code settings file. To use WSL, you must set wallaby.useWsl to true, for example:

{
    "wallaby.useWsl": true
}

This setting is ignored on non-Windows environments. If configuring a custom version of node, the path must refer to a version of node on your Linux installation.

Note that you need to restart the editor after the changes to apply them.

Trial version

Wallaby is installed with a limited-time feature-complete demo license that periodically prompts you to restart your editor to continue using the tool. Free Trial licenses that allow you to evaluate without prompts and restarts are also available.

Troubleshooting

If you encounter any issues with configuring or using Wallaby and are not sure why it happens, check out our troubleshooting docs section or search our public repository issues to see if someone else has experienced something similar.

Another useful technique is to run Wallaby with the trace flag set to true. In this case Wallaby outputs a lot of additional information about the test execution progress which may help you to understand what’s going on if something goes wrong. The output can be viewed in the Wallaby.js Console Output Channel (View - Output).