Is this a good way to write jest tests for an API?

JavaScript
1

For a few years, I have avoided testing and now I’m learning it by applying it to an express API I am working on. I was wondering what the best practices are and if I am thinking about this the right way.

I’m starting the test by connecting to a fresh dabase and adding some seed/dummy data and when the test is complete I delete the database.

beforeAll((done) => {
  mongoose.connect(
    "mongodb://localhost/NoteTakingReact2021-test",
    { useNewUrlParser: true, useUnifiedTopology: true },
    () => {
      Seed.then((value) => {
        done();
      });
    }
  );
});
afterAll((done) => {
  mongoose.connection.dropDatabase(() => {
    mongoose.connection.close(() => {
      done();
    });
  });
});

Most importantly, is it correct to rely on (or to build on) previous tests?

Sorry for the extremely basic and useless example but I’m sure my intentions are clear

const data = { id: "" };
describe("adding to the db", () => {
  test("add book", (done) => {
    const payload = { id: "a123b" };
    data.id = payload.id;
    expect(payload.id).toEqual("a123b");
    done();
  });
  test("see if book is added", (done) => {
    request(app)
      .get(`/api/${data.id}`)
      .end((err, res) => {
        expect("something useful").toEqual("something useful");
        done();
      });
  });
});

Do these tests get run in that exact order, and is the use of data object just as the above the right way to go about it? (I saw examples when to get the idfor the second test people would create the second test as to run in isolation)

Is it ok to work like this (where each test uses the data from the previous test - if need be)?

2

Test are not sequential. Each test block is an independent stand alone unit.

What are doing is closer to an end to test than a unit test. Unit tests are meant to verify small units of functionality. Typically verify single function does what is built to do. Unit tests are not meant to verify that a chain of operations work together to provide an expected result. You can use mocking to provide your own implementation or return values of dependencies which the unit relies on like a database operation. A database operation is typically something that would be mocked in a unit test.

If you think about it it sort of makes sense. Why do you need to test that Mongoose works. That library probably already has its own set of unit tests to prevent regressions. You don’t need to test that mongoose works just that the code/unit you wrote works as expected.

That type of test is typically referred to as an end to end test. Jest is not really the appropriate tool for end to end testing. Especially for an api. I’m not very familiar with end to end api testing landscape of express. However, frameworks like Spring and .NET provide integrated solutions for testing APIs. I’m sure something like that exists that is well known in the nodejs express ecosystem.

There are also stand alone tools available that provide suites to test APIs. The primary one that comes to mind is postman.

https://www.postman.com/use-cases/api-testing-automation/

Actually it does appear devs are using jest for integration testing.

The last time I wrote that type of test was in .NET Framework and .NET has built in API testing.

3

That’s the kind of thing I normally use but I wrote a set of tests that tested all my endpoint and it was a lot easier/quicker than me manually clicking through the postman options.

And I’m not testing mongo (or I thought I wasn’t) I am testing whether my implementation performs the correct CRUD

4

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.