#Help with writing the unit tests

24 messages · Page 1 of 1 (latest)

hidden holly
#

Hi guys
I'm new to this framework and testing
I hear that we should write both the e2e tests and the unit tests
But the point is if I write the e2e tests, I think the unit tests are quite redundant
Does this mean I'm doing something wrong with the e2e tests?🤔

I think it is awesome if you guys can give me an example about this case 😄

native drum
#

E2E tests are usually slow and require setup, such as database migrations, seeding, and possibly external intentions. They can be brittle, and possibly fail on network connection issues

Unit tests, however, should be light, quick, and resilient, testing only a small portion of logic rather than the entire flow of an endpoint.

In the end, balance is the key

hidden holly
#

hmm, in my case , my e2e tests is for testing the api with supertest
so I don't know what should I focus on for the unit test of that api service 🫤

native drum
#

What all does your API service do? Does your e2e test cover the branches of logic?

hidden holly
#

yes, I think the e2e test covers the logic

#

but I'm quite confused that I should write the unit tests or not

#

personally, I believe if the e2e test is good, no need for the unit tests

#

the unit tests are for the cases which are not APIs

#

what do you think about that opinion ?

hoary horizon
# hidden holly yes, I think the e2e test covers the logic

It's not really about the 'e2e' test covering it all, which btw is the wrong label -- don't know how NestJS gets this wrong.

A unit test does not have to be small, it can be a function, class, a component, a system, as long as it meets the following requirements:

  • Can be run in parallel
  • Does not touch fs/database/network or anything that makes it slow
  • Does not change the environment, e.g. configuration.

I don't like to talk about unit or integration tests, a test is either fast or slow. So I will continue with this terminology.

Depending on the complexity of your app and the state you are in, you might prefer slow tests, in specific, acceptance tests. They will cover the most code and give you a good amount of confidence. The problem however, is that this does not scale the moment you app gets more complex.

Speaking from a TDD perspective, we aim for short cycles. Every change should tell us whether we broke something without having to wait for the tests to be ran. This is definitely not possible with slow tests, they are at average 300ms+, where a fast test runs within 1ms.

Now when do you write such tests? In reality, as much as possible. Let the slow tests confirm that the core functionality works, and your fast tests can also verify this behaviour plus more. The harder part about it is understanding the dependencies you are marrying in your tests. Have you ever heard a developer say, well, if I have to refactor... I have to throw away my "unit tests"? That's because they failed to understand the underlying relationships within the system under test.

Hope this helps you 🙂

snow herald
hoary horizon
#

assuming you are the author

snow herald
hoary horizon
#

probably not

#

aha

quick jacinth
#

I've always had problems in my tests that it doesn't recognize @src when I run them so I just remove the @. I've read and tried so many things but finally gave up. If anyone has any suggestions thanks!

native drum
#

You need to update your jest config's moduleNameMapper to tell Jest how to resolve the import

quick jacinth
#

in package.json yea?

"jest": {
    "moduleFileExtensions": [
      "js",
      "json",
      "ts"
    ],
    "modulePaths": [
      "<rootDir>"
    ],
    "rootDir": "./",
    "transform": {
      "^.+\\.(t|j)s$": "ts-jest"
    },
    "collectCoverageFrom": [
      "**/*.(t|j)s"
    ],
    "coverageDirectory": "../coverage",
    "testEnvironment": "node"
  }
native drum
#

If that's where your unit test config is, yes

quick jacinth
#

oh, interesting i also have in test folder a jest-e2e.json

{
  "moduleFileExtensions": [
    "js",
    "json",
    "ts"
  ],
  "rootDir": "../",
  "modulePaths": [
    "<rootDir>"
  ],
  "moduleNameMapper": {
    "^src/(.*)$": "<rootDir>/$1"
  },
  "testEnvironment": "node",
  "testRegex": ".e2e-spec.ts$",
  "transform": {
    "^.+\\.(t|j)s$": "ts-jest"
  }
}
#

it was a template setup from nest cli last year, you put "test" directory outside "src" right?

native drum
#

e2e tests yes, unit tests, not usually (though your setup may be different)

quick jacinth
#

does this look right to recognize @src?

"moduleNameMapper": {
    "^src/(.*)$": "<rootDir>/$1"
},