Arrange should be through API as well? about nodejs-integration-tests-best-practices

[mikicho]

Internal successful change: The coupling argument is a good one. like if something changes the dev needs to change 2 parts in the tests (DAL + API requests) and not only one. API.
I think for now we can stick with API-only arrange (as much as possible) and re-think this in the future if needed.

I'm closing the issue, feel free to continue the discussion/reopen.

[goldbergyoni]

@mikicho Great point, exactly the kind of discussion that will push us perfect the component tests setup. There are no easy wins here, yet another trade-off. Does this table lack any considerations:

	Through API	DB direct
Failure in DB model (e.g. bug in DAL)	🤔👍🏼Not so easy to find the root cause: - Direct and indirect tests will fail (add & get). One should understand that OR Add OR Get has an issue - Logs should display error, we anyway need to assume that a developer can extract the exception easily from logs	👍🏼Just a bit easier to find the root cause: - Direct and indirect tests will fail (add & get). One should understand that OR Add OR Get has an issue - Logs should display error, we anyway need to assume that a developer can extract the exception easily from logs. Logs might be a bit clearer here
Internal successful change in DB model (not bug, just change)	👍🏼 Positive-positive, all pass, no issue	😢 False-positive (failure due to coupling to internals)
Can run in remote mode (API deployed in another network)	👍🏼 Yes	😢 No

[goldbergyoni]

p.s. A valid test name will imply the failure reason:

test('**When adding a new user**, Then is should be retrievable')

[mikicho]

About your nice chart.
Failure in DB model (DAL) is pretty rare, at least relative to application failure. this layer changes the least.
Internal successful change in DB model: you can say the same for API change. a lot of time schema changes are correlated to API changes and vice versa.
Can run in remote mode: do you mean real calls for 3rd party services?

[goldbergyoni]

@mikicho

Failure in DB model - Means bug in your DAL. Your bug. This so common of course. For example, it means things like you added a new mandatory column but some route in your code doesn't provide that new field. Would you really say that changes in the data-access layer + DB are rare?

Internal successful change - Yes, it can change too, but then your tests are coupled to one layer and not to a few. Also, API changes sometimes are documented with OpenAPI and there are tests that show when you are deviating from the Swagger spec (we will show this hopefully)

Remote mode - When you want to run the same tests against your remote staging or production. Not 3rd party rather your Microservice which lives out of of the tests process

Is it clear now? What would you choose then? I like how you question our beliefs, keep being skeptical, this is our way to ENSURE we're suggesting the right things:)