CODEWITHSUNDEEP
node.jstestingmocha.jsbddchai
losik123
losik123

Reputation: 590

How to avoid code redundancy in large amounts of Node.JS BDD tests

For the last few months, I was working on the backend (REST API) of a quite big project that we started from scratch. We were following BDD (behavior-driven-development) standards, so now we have a large amount of tests (~1000). The tests were written using chai - a BDD framework for Node.JS, but I think that this question can be expanded to general good practices when writing tests.

At first, we tried to avoid code redundancy as much as possible and it went quite well. As the number of lines of code and people working on the project grew it was becoming more and more chaotical, but readable. Sometimes minor changes in the code that could be applied in 15 minutes caused the need to change e.g. mock data and methods in 30+ files etc which meant 6 hours of changes and running tests (extreme example).

TL:DR

We want to refactor now these BDD tests. As an example we have such a function: 

function RegisterUserAndGetJWTToken(user_data, next: any){
    chai.request(server).post(REGISTER_URL).send(user_data).end((err: any, res: any) => {
        token = res.body.token;
        next(token);
    })
}

This function is used in most of our test files. Does it make sense to create something like a test-suite that would contain this kind of functions or are there better ways to avoid redundancy when writing tests? Then we could use imports like these:

import {RegisterUserAndGetJWTToken} from "./test-suite";
import {user_data} from "./test-mock-data";

EDIT: Forgot to mention - I mean integration tests.

Thanks in advance!

Upvotes: 0

Views: 256

Answers (1)

Krzysztof Jelski
Krzysztof Jelski

Reputation: 342

Refactoring current test suite

Your principle should be raising the level of abstraction in the tests themselves. This means that a test should consist of high-level method calls, expressed in domain language. For example:

registerUser('John', '[email protected]')

lastEmail = getLastEmailSent()

lastEmail.receipient.should.be '[email protected]'
lastEmail.contents.should.contain 'Dear John'

Now in the implementation of those methods, there could be a lot of things happening. In particular, the registerUser function could do a post request (like in your example). The getLastEmailSent could read from a message queue or a fake SMTP server. The thing is you hide the details behind an API.

If you follow this principle, you end up creating an Automation Layer - a domain-oriented, programmatic API to your system. When creating this layer, you follow all the good design principles, like DRY.

The benefit is that when a change in the code happens, there will be only one place to change in the test code - in the Automation Layer, and not in the test themselves.

I see that what you propose (extracting the RegisterUserAndGetJWTToken and test data) is a good step towards creating an automation layer. I wouldn't worry about the require calls. I don't see any reason for not being explicit about what our test depends on. Maybe at a later stage some of those could be gathered in larger modules (registration, emailing etc.).

Good practices towards a maintainable test suite

  1. Automate at the right level.

    Sometimes it's better to go through the UI or REST, but often a direct call to a function will be more sensible. For example, if you write a test for calculating taxes on an invoice, going through the whole application for each of the test-cases would be an overkill. It's much better to leave one end-to-end test see if all the pieces act together, and automate all the specific cases at the lowest possible level. That way we get both good coverage, as well as speed and robustness of the test-suite.

  2. The guiding principle when writing a test is readability.

    You can refer to this discussion for a good explanation.

  3. Treat your test helper code / Automation Layer with the same care as you treat your production code.

    This means you should refactor it with great care and attention, following all the good design principles.

Upvotes: 1

Related Questions