Giters

testjavascript / nodejs-integration-tests-best-practices

✅ Beyond the basics of Node.js testing. Including a super-comprehensive best practices list and an example app (March 2024)

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Add and test a GET route

goldbergyoni opened this issue · comments

commented

Currently the example app shows only /POST tests, we should add /GET and in overall ensure we have tests for the basic integration KATA:

For each scenario, one should test at least the following:

  1. API response ✅
  2. The after state - Whether the system has the right data now, usually using /GET request. We don't have this ❗️
  3. External call was made - For example, when email/SMS should get sent. Do we have this? ❓
  4. Invalid input - Do we have this ❓
  5. 3rd party failure simulation - If interacting with external service, ensure we react fine to failure. Do we have this? ❓
commented

Take a look here.

I’ve added:

  • a getById and clear methods to the repo.
  • a get route with an id as a param.
  • Also, now when an order is placed successfully we send an email to the admin.

At the basic-tests file the first five tests correspond in the same order to the points you made in this topic. The last one (When order failed…) is not well fit here in my opinion, because it checks the error handling function instead of the /post route.

I clear all records once inside afterAll (with the clear method on the repo).

commented

@DanielGluskin Great push man. Let's delve into all the details with a PR, one fundamental point: Data teardown should happen in global-teardown, not per suite (file) otherwise tests will just fail. Tests run In multi-processes (when there are multiple files), when process1.test-file2. is destroying all tables, at the same time process2.test-file3 is running and suddenly the DB is empty...

Suggestion - In global-teardown, delete all data tables. Why not truncate? IMO delete is faster, if you run a benchmark with 100k records it could be awesome. Also, exclude metadata tables from the deletion so we don't have to seed on every run - For example, there is no point in deleting the countries/currencies table.

commented

Good points indeed, but this leads to a few issues:

  • We need to randomize our data.
  • How do we test getAll routes?

Perhaps each test (or file) can run within a transaction which will be rolled-back at the end?

commented

@DanielGluskin Good point indeed2. Take a look first at our best practices list, find the section "Dealing with data".. The text is draft, just ideas, not the final phrasing.

We anyway need to randomize data - Within the same file, test num-38 might try to add the user 'joe' which test num-2 already added (unique column). We don't expect test writers to read 50 tests before they write one. So one should add joe-${something-short-and-unique}

Get all routes - It's fair to assume, that if all the records that the test added are returned in getAll -> Then the code works. Example:

// Arrange
add record1, record2

// Act
result = getAll()

// Expect
record1 & record2 are in result. Maybe also others but I don't care.

What's wrong with transactions - Read in the BP my thoughts on what's wrong with transactions.

Curious to hear your thought...

cc @mikicho

commented

Agreed for both points. I'll take the cleaning and randomization out of this branch, as the point was only to create a get route. Seems OK?

commented