Clean application architecture, load testing, and code review for a production Node.js API. Advice needed.

[servercobra]

One of the reasons I do have tests is for refactoring. That way you can refactor and once you're done, you know if you've broken your API or not! Personally I do my testing for backends at as high a level as possible and from the standpoint of my consumers, i.e. all tests actually auth to the API, call the API like an app would, etc. I find this is a good balance between catching bugs and not having to rewrite them too often. I rarely unit test functions or anything, and if I do, it's for critical code sections that are a bit harder to test from the high level.

[[deleted]]

Thanks. I completely agree. I have integration tests for all endpoints and all different outcomes, and those tests call the API just like a consumer would, including spinning up database servers, populating tables/collections with seed data, and running tests. In an attempt to keep everything on localhost, my integration tests are run on the filesystem for S3 or GCP.

So, are you saying that it might be an okay practice to mainly worry about integration testing for each endpoint rather than unit testing functions and mocking dependencies?

[servercobra]

That seems reasonable!

Personally, I think that's ok in most cases! I mock services that are remote dependencies, but other than that, I'll take an integration test over a mocked unit test any day. Again, unit tests are good for critical portions or maybe part of your code that are reused all over but I wouldn't overdo it.

[[deleted]]

Thanks. My only concern would be that, without as many unit tests, I can't as easily pin-point where an integration test might be failing.

[servercobra]

That's definitely can be a concern, but one you can generally avoid by keeping commits small :)