Mikbe.com

Why and How Testing Can Make You Happier

Fri, 11 Mar 2016 17:32:00 +0000

I was once a non-tester, because I didn’t see the value. Then I tried it for a while, and was convinced. I’ve gathered some experience, but not enough. This article is an attempt to collect what I know and what I think I know, and hope I can finally learn some of the stuff I know but don’t necessarily practice.

The main inspiration source for this article is JavaScript Air episode 004, but there’s also some original content in here. And some from TDD: Where did it all go wrong?.

I don’t always test my code, but when I do, it feels better.

– me

What is it all about?

This, only for code:

The concept isn’t that hard.

This article is mostly about unit testing, as opposed to integration testing or end-to-end testing, but some aspects are true for all kinds. And know that there’s a spectrum. In practice, tests are seldom one or the other, and that isn’t the goal either.

Unit tests are cheap and should make up the largest part of your testing efforts. They’re cheap to write and run. They look at only specific parts of the code. Integration tests are the opposite, they encompass larger parts of the code. Some mimic users.

Why is it Important?

Testing helps you achieve peace of mind about your code. Writing a solution to a half-complex problem, then manually testing it only takes you so far. With some experience, you’ll surely recognize the situation of shipping some code with confidence, only to find it break apart at its first opportunity.

Testing gives experience with the mindset of putting your code under the most extreme conditions it can get into. What if the number passed in was negative when we always assumed it would be positive? What if it wasn’t a number at all?

Everybody writes bugs, we all write bugs. So, it’s not a matter of “can you write code correctly or not the first time?”, we all write incorrect code. That’s all that we do, we only write incorrect code.

– Joe Eames, JavaScript Air 004

Coding is hard, and we should all acknowledge that. Among the primary reasons to test your code is to gain confidence that it will behave as expected, whatever that is.

Not convinced? Here are some additional arguments:

Tested Code is Better Code

Many people^[who?] will tell you that code testing leads to better code quality. This is especially true when using unit tests and at least some variation on test driven development, even if it’s a sloppy one. Here’s why:

If your code is hard to test, then it’s probably not very well written. What identifies good code is a large question, but the emphasized sentence here is a good rule of thumb. A quality of good code that most will agree on is that it separates concerns. Experienced programmers limit function bodies to only do one logical thing for this reason.

Aligning Your Goals

Code that is hard to test probably has either too many things going on, or too many dependencies (or both). Think of this as a problem of aligning interests: When writing untested code, there is a conflict of interest between speed (or laziness) and separation of concerns, and it doesn’t matter as much for the short term how your code is structured. When your code has to be tested, your goals are more aligned, because tests are easier to write for well written code!

Think as a Consumer

When you’re writing tests first, you’re designing your code’s API first. Testing puts you into code consumer mode, where you’ll write code against what’s going to be the interface to other stuff. Designing your API without so much concern for inner workings leads to a better API design, which leads to easier consumption of your module, which leads to cleaner code in the project as a whole.

Eureka moments

Testing leads to a-ha moments. Often because it forces you to think about edge cases – the value zero, 10^12, null or undefined. You’ll have the opportunity to think about, reflect on and acknowledge what should happen under strange circumstances. Merely the process of thinking about them, or other situations your code can face, often leads to realizations of how the code can be simplified (as well as how it has to guard itself).

These eureka moments can also come from one of the most frustrating situations: when your code and tests don’t agree. You’re put in the situation of having to decide which is right. If you’re in this situation, something has probably gone wrong with the design, or your assumptions have changed. Think of this as a good sign! Your code will be happier.

Tests Document What the Code Does

No-one loves to write documentation, but it sure as hell is nice when the module your inheriting (from your one year younger self, or someone else) or interfacing is well documented. Tests can be this documentation, and with an added bonus: tests put their money where their mouths are and demonstrate what they mean. Like the best science teachers, they don’t just tell you that hydrogen is flammable. They fill a balloon with hydrogen, let it rise to the ceiling and put a lighted match on a stick to it (One of my most memorable 5th grade classes).

Do you know what is common to all bugs? They passed all the tests. So when you find one, you know where not to look.

At least you know what doesn’t work.

Testing makes it easier to join a project, because they reveal what the code is actually supposed to do. They tell a story about the design decisions, what went through the mind of the original developer.

Refactor Without Worry

Ever looked at a horrible mess of code, but been to afraid to clean it up? The first thing I do in situations like that is to create tests to discover what the code is supposed to be doing. The tests lock down the functionality, in a good way, allowing us to focus on the spring cleaning, rather than worrying about breaking stuff.

I’ve seen pieces of code so bad they cause real concerns of whether they actually do what they’re supposed to. Still, no-one dared touch it, afraid of not only breaking intended functionality, but also breaking bugs. I suspect a large test set based on past I/O would be well worth its investment.

Fun fact, the feelings of worry and happiness are inversely proportional. Or something like that.

Create Value with Confidence and Correct Products

Correct code is more valuable than incorrect code^{[citation needed]}. Everything helping your code to be correcter tahn what was there before is worth taking a look at, it’s as simple as that. Delivering correct code builds up trust over time, trust is a valuable asset.

A Tool to Use Less Brain RAM

Here’s a tip: Don’t try to solve a problem and engineer a nice solution at the same time. Testing gives us that opportunity, using this recipe from Ian Cooper’s talk on TDD:

Write a red test.
Solve the problem, make it green as fast as possible.
Engineer a nice solution, refactor it to something you’re proud of.

The important thing to take away here is the temporal separation of concerns in your head. Do not try to do steps 2 and 3 at the same time. One of the main limitations of programming is how much you can keep in your head at once, and you’ll write better code the less you have to keep there when you’re typing.

When solving the problem, do not think about how the code really should be. Copy-paste code, write inefficient loops, duplicate stuff, do whatever you have to do to get the test green as fast as possible. Then think about how to change it into something you could show your mother.

Separating your own concerns is one of the reasons to test in the first place, and this method helps doing it in practice. When you quickly and dirtily race to a solution, you don’t have to think about how it looks or how fast it runs. When you carve out your nicely engineered and cool solution, you don’t have to worry about screwing something up.

Knowing What to Test is Key

Knowing what to test isn’t as easy as it sounds, and is definitively something that comes with experience. Many test too much. Knowing what to test is related to understanding what is important, and what isn’t, and knowing that is not trivial. Here’s a tip, though:

Test at the highest level possible to get coverage and flexibility on implementation.

– Brian Lonsdorf, JavaScript Air 004

So, basically:

Do not test internal stuff, it will only get in your way. If you honestly feel like you should test the internal stuff, then you might be better off separating some of the internals out to a new module, where they are external.
Do not allow tests to be over specified and deal with stuff they don’t have to or shouldn’t know about.
Do not write tests just to get 100 % coverage. If someone tells you to always have 100 % coverage, no matter what, then punch them in the face.

Remember that tests should be written outside-in, from a perspective outside the module. Note that full test coverage should still be possible, i.e. all branches of your code should still be reachable. If they’re not, they’re basically dead code, right? Test the internals only if you need to understand better how they work.

Think about what happens when the code is refactored, some time in the future. The implementation should be allowed to change without tests failing. Why? Well, because if the future coder has to change the tests, then it’s basically a rewrite, not a refactor. And rewrites aren’t safe. There should be no new tests for refactoring internals.

Be pragmatic about what to test. Testing is part of the project, part of the value creation, and it doesn’t make sense to test just anything, just like it doesn’t make sense to implement every button. Remember the documentation aspect. If tests are mostly involved with implementation details, we loose the focus on what’s important in the module. We loose the documentation value.

About documentation, test your domain assumptions. These are the code interpretations of the problem domain you’re working in, often something where the programmer is not the expert. Documenting these assumptions in code form solves two problems: documenting the assumptions themselves, and proving that they work as interpreted.

Write a test when you find a bug. Don’t just fix it, but prove for yourself and others that you’ve actually done so. Write a test, and make sure it’s both red and aligned what the expectation would be not aware of the bug. Fix the bug, make it green. Save the day.

Code coverage is overrated as a concrete number, but useful as a tool. Do not strive to cover for coverage’s sake. Remember that coverage only tells you what lines your tests run, but not in what combination they will run. However, it can be a good indication of whether things are moving in the right direction. If a refactor leads to poorer code coverage, then some bells should be ringing, especially if it’s a refactor. Do not allow yourself to write tests just to increase the number. Well tested and written code will have a higher number.

The trigger for writing a test is when you’ve got a new piece of behavior. The tests should capture that behavior, but no more.

Testing libraries might be both easier and more important than testing end applications. After all, libraries will be used by multiple applications.

How To Write Awesome Tests

Knowing how to write good tests is key, because it’s very easy to write them badly. The truth is, as with everything, that it takes practice. Still, here are some tips.

A good test is a simple test. It doesn’t try to cover everything in one go. It’s name should reflect what it does, and the name should fit comfortably in one line. The name shouldn’t be “it works”, but rather, “it returns 0 for negative values”

A good test is a simple test.

Make sure not to overspecify your test. Overspecified tests know too much about internals for their own good, and don’t allow refactoring.

A unit test runs the code in isolation from other tests, not necessarily other code. It takes the code out of it’s context, and creates an artificial context from which an aspect of it can be investigated. However, that does not mean a unit test has to run in isolation from all other code, even though this is often cited as “pure unit tests”. Everything does not have to be mocked, stubbed or spied on, leading to more complex setups, lower coverage and more fragile tests.

Use mocks or stubs where that makes sense. You don’t want to test against a real HTTP API, but stub them out. Use a mock or a stub if what you’re testing is your own call to that object, or if you want to lead your own code down a certain path.

A test should read like a small story, following the AAA system: Arrange, Act, Assert. You set things up, you make some statement, and you assert that the statement did what the statement should. The “small story” aspect has emphasis on small. None of the “A”-s should be more than about 3 lines. Making some space between the phases can be nice. It should contain no branching or looping, and you should assert only one logical thing. (It’s nice if that can be expressed as one assert statement, but sometimes you’ll need more, and that’s OK.) Never assert in two different places in the test, as this causes confusion as to what you’re actually testing.

The test should be readable with only some domain knowledge. If it does things that are hard to explain without going into the inner workings of the module, then it’s probably better to either spend some more time on the test, or just leave it out completely.

Generally, don’t test your dependencies. For certain projects, it may make sense to do some simple testing of the assumptions your own code is making, but do so sparingly and with caution. Testing a library is the job of the library author. Instead, rely on changelogs for upgrades, and on testing your integration against the library (this is a reason not to mock everything).

Write cheap tests that don’t take forever to run, because run them as often as possible. If you can pass a --watch argument to your test runner and have it run every time a file is changed, then that’s a good thing.

Last but not least, use a test framework you like working with. If JavaScript is your thing, I’d like to recommend AVA 🚀 because of it’s clarity, simplicity and lack of complex configuration. Whatever you choose, make sure it’s something that works with you and helps you write efficiently and fast. As with everything code, if it’s not fun, something is probably wrong.

Give Your Releases Awesome Names with Codenamer

Sun, 14 Feb 2016 12:36:01 +0000

TL;DR: I’ve released Codenamer, a simple CLI to generate codenames. Such as it’s own release codename, 0.3.0 canonical-catastrophe.

$ curl -s https://en.wikipedia.org/wiki/Gravitational_Waves | codenamer --format pa,cJ,n15-cN,a,n20
astronomical-amplification

Using codenames for releases has been one of my hobbies, ever since I started using Angular, inspired by their cool-sounding and mysterious codenames.

Using names for releases in large-ish projects can make them easier to remember and to talk about. Even if the name is totally unrelated to the contents of a release, it can be easier to relate a feature set to a name than to an arbitrary number.

In order to be extra cool, codenames should:

Sound awesome
Keep to a theme
Fulfill a set of rules, e.g. <adjective>-<noun>
Optionally relate to the release number, e.g. start with a for 0.1.x.
Alliterations are welcome.

Using Codenamer

Codenamer lets you generate these memorable codenames without need for imagination. You just pipe it a (fairly large) body of text as input, and some rules for the codenames.

$ curl -s https://en.wikipedia.org/wiki/Alliteration | codenamer --count 10 --format cJ,n15-cN,a,n20
persuasive-parallelism
specific-syllables
symmetrical-syllable
consonant-consonants
alliterative-argument
pickled-proposition
special-speaker
rhetorical-release
memorable-meter
potential-pairs

The format option lets you specify the number of words per codename, the length of each word (or the combined length), the word class for each of the words and alliteration.

The module also has a Node API, so you can generate codenames as part of a release script or something.

Install it with npm install --global codenamer, and you’re ready.

Check the repo at mikberg/codenamer.

Zero to Hero with End-to-End testing using Nightwatch, SauceLabs and Travis

Sat, 23 Jan 2016 13:59:43 +0000

Developing super cool web apps has always been a walk on a thin line: You want to use the latest possible language features and APIs, but at the same time, it needs to work in loads of, for developers, obscure browsers like IE10 and Android Browser.

Deploying quickly grinds to a holt when you find out in final tests that your app doesn’t work in all of the required browsers and environments, and last minute hacks are sometimes needed. Using a continuous integration testing tool with real-life browsers was a real timesaver and stress-reliever for me.

This is a summary of the feature branch that took me there.

Prerequisites

In order to get something tested at all, we need two ingredients: A browser automation tool and a test runner. For browser automation, Selenium is the obvious option, and the one cloud testing providers like BrowserStack and SauceLabs use.

If you’re on OSX, run brew install selenium-server-standalone, along with a webdriver for your favourite browser: brew install chromedriver. Run it with selenium-server -p 4444.

There are many test runners which integrate with Selenium. You can choose any test runner you want, so choose one that makes sense for you, based on programming language and needs. This article is based on Nightwatch, but should be easily translatable for other test runners.

Go ahead and install Nightwatch with npm install -g nightwatch.

Configuring Nightwatch

Nightwatch needs some config, so create a new file called nightwatch.js. Nightwatch uses a .json config file as default, but using a JS one allows us to do some smart stuff later, like generating parts of the config based on environment variables.

// nightwatch.js
module.exports = {
  src_folders: ['test/e2e/'],
  ...
};

Find the rest of the configuration you need in Nightwatch’ developer guide. In the default configuration, just use the browserName corresponding to the Selenium webdriver you installed, e.g. chrome.

Creating your first test

Time to write some code! Create a file test/e2e/simple/simpleTest.jsand paste in something like this:

// test/e2e/simple/simpleTest.js
module.exports = {
  beforeEach: browser => {
    browser
      .url('http://localhost:8000')
      .waitForElementVisible(‘body’)
      .waitForElementVisible(‘#app > div’);
  },
  ‘Smoke test’: browser => {
    browser
      .assert.visible(‘#app > div’, ‘Check if app has rendered with   React’)
      .assert.title(‘MyTitle’);
  },
  after: browser => browser.end(),
};

Thanks to the Nightwatch API, the code is pretty self explanatory. Replace the assertions with something that makes sense for you.

Assuming you already have your app running, go ahead and run your test, with nightwatch --config nightwatch.js.

Awesome, the title matches the HTML.

Running Tests in the Cloud

Useful as it is to test whether Chrome can parse HTML, we’re now ready to 10x the awesomeness, using SauceLabs. Feel free to create an account at this point.

First, make some changes to the Nightwatch config:

default: {
  launch_url: 'http://ondemand.saucelabs.com:80',
  selenium_port: 80,
  selenium_host: 'ondemand.saucelabs.com',
  silent: true,
  username: process.env.SAUCE_USERNAME,
  access_key: process.env.SAUCE_ACCESS_KEY,
  screenshots: {
    enabled: false,
    path: ‘’,
  },
  globals: {
    waitForConditionTimeout: 10000,
  },
},

(You can move your previous default config to one called e.g. “local”.)

Nightwatch needs your username and access key to connect to SauceLabs. We also use the opportunity to add a global default time for Nightwatch’ timeouts.

At the same level as the default configuration, add one or two browsers you want to test against:

chrome: {
  desiredCapabilities: {
    browserName: 'chrome',
    platform: 'OS X 10.11',
    version: '47',
  },
},
ie11: {
  desiredCapabilities: {
    browserName: 'internet explorer',
    platform: 'Windows 10',
    version: '11.0'
  }
}

Set your SauceLabs username and access key environment variables with export SAUCE_USERNAME <username>.

For SauceLabs to be able to contact your server, install SauceConnect with brew install sauce-connect, then run it with sc -u <USERNAME> -k <ACCESS_KEY>.

This should be all it takes to run tests on a machine far, far away, somewhere in a cloud, and have it do stuff the server running right under your fingertips. Run nightwatch --config nightwatch.js --env chrome, then sit back and relax.

Not bad, Chrome and IE agree on the title.

Run Your Tests from Travis

This step requires us to make Travis spawn both a server to host our app, and a tunnel to SauceLabs with SauceConnect. Worry not, because it’s not that hard.

For more documentation, read Travis’ article.

addons:
  sauce_connect: true
install:
  - nvm install 4.0 // if you're not using Node as language
  - npm install -g nightwatch
before_script:
  // This is our server
  - npm run serve:dist &
script:
  - nightwatch --config nightwatch.js --env chrome,ie11
  // This one feels hacky, but does the job of killing the server
  - pkill node

Note: If your server takes a very long time to load, it can be a good idea to add a “sleep 30” command after you start the server.

Also note: You probably have some other stuff you want travis to do. Do them before Nightwatch, as the tests involving SauceLabs are probably the most expensive. You’ll also give your server some time to build JavaScript.

For SauceLabs to connect to Travis, we need to send them a tunnel identifier. We’d also like SauceLabs to take a note of the Travis build number it is testing, so we also pass that one. Luckily, they’re both based on the same value.

// nightwatch.js
const TRAVIS_JOB_NUMBER = process.env.TRAVIS_JOB_NUMBER;
// in test_settings.default:
default: {
  launc_url: 'http://ondemand.saucelabs.com:80',
  ...
  desiredCapabilities: {
    build: `build-${TRAVIS_JOB_NUMBER}`,
    'tunnel-identifier': TRAVIS_JOB_NUMBER,
  },
}

Congratulations, the next time you push your code, servers around the world will collaborate to make sure everything works as intended.

Gather some friends to watch in awe as results tick into the SauceLabs dashboard, with live videos and things flashing all over the screen.

Make SauceLabs know whether or not it worked

You might have noticed the nice question mark next to each of your tests in SauceLabs. It appears because while it provided Nightwatch with a nice API for it to run commands an queries, it’s completely oblivious to whether or not it was expected. In order to get some nice check marks (or red exclamation marks), we need to report SauceLabs about the outcomes.

Here’s an example implementation in the form of a Gist, inspired by this code.

Edit your test to run the sauce function when it tears down:

const sauce = require('../sauce');
module.exports = {
  //...
  tearDown: sauce,
};

Result:

Awesome. Add some better tests, add more obscure browsers, like Android 4.0. Now, only be a little bit nervous about browsers on each commit, rather than terrified when releasing.

Writing Simple Unit Tests with Relay

Tue, 19 Jan 2016 13:59:43 +0000

Ever since I started using Relay in my React projects, code coverage has dropped significantly in their code bases. Testing Relay containers is not trivial, and the project definitively lacks a test tool. There I decided to make an effort and a write-up of my findings.

Mock Relay gist: https://gist.github.com/mikberg/07b4006e22aacf31ffe6

Getting Started: Mocking Relay

To get any testing done, Relay must be mocked to prevent invariant violations such as this one:

Invariant Violation: RelayContainer: `Relay(Main)` was rendered without a valid route.

If you’re using Jest, then it’s both automatic and a piece of cake.

If not, then mocking a dependency might be trickier, but if you’re using Webpack, then I’ve got this trick up my sleeve:

// webpack.test.config.js (webpack config used in tests)
module.exports = {
  resolve: {
    alias: {
      'react-relay': /* path to mock relay */,
      'real-react-relay': path.join(__dirname, '/../node_modules/react-relay/'),
    }
  },
};

In other words: During tests, importing react-relay resolves to our mock Relay module, while the real Relay module is available as real-react-relay.

Using this, we can write our mock module like this:

// Our mock Relay module
import Relay from 'real-react-relay';
export const QL = Relay.QL;
// ...

I’ve published my mock Relay module as a gist, if you’re interested, heavily inspired by this comment to facebook/relay#161.

Testing Containers

Alrighty, we have successfully mocked Relay and are ready to write some actual tests. In the mock Relay module, that createContainer simply returns the container class itself.

createContainer: component => component

That makes rendering the component with fixtures super simple, we can just give it to the component as props:

const fixtures = {
  viewer: {
    id: ‘myid’,
    hasNewNotifications: false,
  }
};
const element = TestUtils.renderIntoDocument(<MyContainer {...fixtures} />);

We can now test that the component renders correctly with every possible data combination from Relay. We can also test static methods. Yay!
In order to test our Relay specs, the second argument sent to Relay.createContainer, we modify the mock’s method to sneakily attach its own method to the container class:

...
createContainer: (component, specs) => {
  /* eslint no-param-reassign:0 */
  component.getRelaySpecs = () => specs;
  return component;
},
...

Testing becomes a breeze:

// Test our prepareVariables method
const variables = { id: 1 };
expect(MyContainer.getRelaySpecs().prepareVariables(variables))
  .to.equal(variables);

Testing the execution of mutations is mentioned in the bottom of the article.

Testing Queries

Whether or not it is strictly necessary to test the Relay queries, the Relay.QL… parts, is up for debate. You’ll probably be pretty safe leaving it out, as they are automatically validated against Relay’s schema.

The real problem here is that the Babel Relay plugin transforms our queries before they are evaluated by the Relay.QL function; thus it can’t easily be mocked or proxied. If we try to mock it, our mock won’t even be evaluated, because the whole expression is replaced before it’s evaluated.

As far as I know, there’s not really any efficient way of testing the queries other than running tests on the objects they are transformed into.

// isMatch from lodash -- I'm sure there's a library
// implementing this method too, leave a note if you know one.
function findDeep(object, compare) {
  if (compare(object)) {
    return object;
  }
  if (typeof object === 'object') {
    for (const key in object) {
      if ({}.hasOwnProperty.call(object, key)) {
        const result = findDeep(object[key], compare);
        if (result) {
          return result;
        }
      }
    }
  }
}
// This is a pretty stupid test
it(‘queries an ID’, () => {
  const query = MyContainer.getRelaySpecs().fragments.viewer();
  const needle = { fieldName: ‘id’ };
  const result = findDeep(viewerQuery, (obj) => isMatch(obj, needle));
  expect(result.type).to.equal(‘ID’);
});

It does increase the code coverage, though not in a very useful way.

Testing Mutations

Most of the mutation objects is straight forward to test. getVariables, for instance, should be a breeze under most circumstances.

const mutation = new CreateEventMutation(inFixtures);
expect(mutation.getVariables(inFixtures))
  .to.deep.equal({ event: inFixtures.event });

In most cases however, we’ll get a warning that parts of the fixtures we use to create the mutation really should have come from Relay. With components, we mocked createContainer to return the component itself (with some extras), so that we could pass in fixtures as props. We’ll do a similar trick for mutations:

// In our mock Relay module
export class Mutation extends Relay.Mutation {
  _resolveProps(props) {
    this.props = props;
  }
}

Configs from getConfigs() can be a bit trickier to test. Since they are mostly about defining stuff, I guess that’s not the end of the world.

it(‘correlates input viewer id to returned viewer id’, () => {
  const fieldsChange = mutation.getConfigs()
    .find(config => config.type === ‘FIELDS_CHANGE’);
  expect(fieldsChange.fieldIDs.viewer)
    .to.equal(inFixtures.viewer.id);
});

it(‘requires event.id to be fetched’, () => {
  const requiredChildren = mutation.getConfigs()
    .find(config => config.type === ‘REQUIRED_CHILDREN’);
  const event = findDeep(requiredChildren, obj =>
    isMatch(obj, { type: ‘Event’ }));
  expect(!!findDeep(event, obj =>
    isMatch(obj, { fieldName: ‘id’ }))).to.equal(true);
 });

Test Mutation Usage

The last point is the touch point between our components and mutations. To get this tested, we can simply use Sinon to stub them into the behaviour that we want: calling either the onSuccess or the onFailure callback.

But this would require us to stub the methods every time, which can become cumbersome. I opted to create a special class:

export class MockStore {
  reset() {
    this.successResponse = undefined;
  }
  succeedWith(response) {
    this.reset();
    this.successResponse = response;
  }
  ...
}

See the rest of the class in the Github Gist.

That allows us to use Sinon to create stubs directing our code the way we want:

it(‘redirects to the new event on success’, () => {
  elem.context = {
    router: {
      replace: sinon.spy(),
    },
  };
  Relay.Store.succeedWith({ createEvent: { event: { id: ‘A’ } } });
  elem._handleSubmit(e);
  expect(elem.context.router.replace.calledWith(‘/events/A/’))
    .to.equal(true);
});

it(‘logs error on failure’, () => {
  sinon.stub(console, ‘error’);
  Relay.Store.failWith({ getError: () => ‘error’ });
  elem._handleSubmit(e);
  expect(console.error.calledWith(‘error’)).to.equal(true);
  console.error.restore();
});

Combining all of the techniques above, we at least have a starting point for testing Relay applications. I must admit I still find testability a pain point with Relay apps, and simply because the unit tests work, I wouldn’t be completely confident about the app’s health before actually running it.

I think it could be healthy to use some simple integration tests to verify that the application works.