Hands up who loves writing software tests?
No-one, oh okay...

Testing is one of those subjects that puts most developers to sleep but today I'm going to show you how to test your app without even thinking about it.

Why Bother With Software Testing?

If you're not familiar with software testing you probably aren't writing tests, and that's ok – I forgive you because I hate writing tests too.

If you are writing tests, then give yourself a pat on the back because tests are one of the most important and overlooked aspects of your development workflow.

It's easy to brush off writing tests with excuses like you're too early stage for testing, but this is a fatal error in thinking.

Imagine you shipped a new feature and your sign up flow breaks.

Should you wait until a user tells you? The user that reaches out could be the 100th user who experienced the problem - the other 99 abandoned your product because you failed to test.

I don't believe there is any excuse to justify this scenario, no-one wants to lose a potential customer.

'But I test everything myself, Kyle!' you might say.

Is that really efficient use of your time? Do you do this accurately every single time you make a change? What happens if an API that your application depends on breaks. How will you find out?

Ok, I'll stop lecturing you. Hopefully you should now be aware of the importance of testing, no matter what stage your business is at.

Let's look at the different tools available to you for testing.

1. Unit Tests

These granular tests are designed to test the smallest components of your application. For example, let's assume you have a function that multiplies two numbers together:

function multiply(x, y){
 return x * y;
}

A unit test for this might look like:

if (multiply(5, 5) === 25){
 console.log('multiply test passed')
}

You test small units of your application with some sample data to ensure the output is as expected.

Unit tests are a good starting point but used in isolation they don't provide a robust framework for testing.

2. Integration Tests

The problem with unit tests is that they don't simulate a typical application flow. In a real-world scenario, the multiply function above is likely to be part of a much larger and more complex system of statements.

The unit test may work perfectly, but there may be other issues in the chain. That isn't to say you shouldn't use them, you should - but you should use them in combination with other tools.

This is where integration tests come in.

Testing frameworks like Mocha and Chia enable you to test large groups of functionality by simulating an API call and then testing for a specific set of results.

For example, here is an integration test from Gravity that tests the process of registering a new free account:

describe('POST /account', () => {
  it ('should create a new free account', done => {

    chai.request(server)
    .post('/api/account')
    .send(config.account.free)
    .end((err, res) => {

      const account = res.body;
      res.should.have.status(200);
      account.token.should.be.a('string');
      account.plan.should.eq('free');
      account.subscription.should.eq('active');
      done();

    });
  });
});

Here, we're automating the API call and testing that the response contains:

• a token (string)

• a variable called plan is equal to 'free'

• a variable called subscription is 'active'

This is much more powerful than a unit test because we can uncover errors in complex systems. The code that is being called behind the scenes by the API endpoint in this example contains a very complex chain of statements and would require many unit tests executed in a specific order to test.

The Problem with Unit & Integration Tests

There is one glaring problem with both of these testing methodologies: they don't simulate real user behaviour.

You can write unit and integration tests like a wizard but if the feature fails in the browser you won't detect it.

Your users won't care about your great unit tests if they can't even submit the sign up form to use your app.

The solution?

Browser Tests

If you want to test real user behaviour, you will need to write tests that simulate real actions within the browser. There are a few ways to do this, you could write tests using Selenium or using a headless browser like Google Chrome.

A browser test will enable you to simulate real behaviour and test the results of complex chains of commands like you would with an integration test.

Sounds perfect, right?

The problem with browser tests is the complexity of creating them; automating a browser is not as simple as writing a unit or integration test and attempting to consistently and reliably load a headless browser on a server as part of your CI pipeline is no easy technical feat.

Introducing Firelab

If like most developers, you don't want to spend days figuring out new frameworks and writing code to run tests when you should be focusing on delivering value to your customers, you'll love Firelab.

I built Firelab to empower developers to build full browser tests without writing any code.

Here's how it works:

1. You create a test and add some actions using CSS selectors, like type 'user@firelab.io' into input[name=email]
2. You define the metrics you expect from the results, like HTTP 200 Status from /api/account

That's it! These tests are super-easy to set up and require ZERO code. See it in action below 👇

You set them up once then schedule them to run continuously every day, week or month or whenever you deploy a code change.

Firelab handles all the complicated technical stuff, like launching the browser, so you can focus on building valuable features instead of sinking weeks into writing tests.

Want to join the exclusive private beta? Request early access now 👇