Open popov654 opened 5 months ago
this apparently breaks the tests pretty badly
this apparently breaks the tests pretty badly
I guess something else has gone wrong here, because I ran the tests locally on this branch, and it is just fine.
I ran the tests locally on this branch
What tests? The failure is from e2e test suite, not from the unit tests.
I ran the tests locally on this branch
What tests? The failure is from e2e test suite, not from the unit tests.
Ah, got it. OK, I'll try to figure out how to fix this. Unfortunately, for now I have no idea why does not my current code work. The swagger.json
schema looks right
Can you please help me with this thing? I'm quite new to Swagger and testing in Node.
Did you try reverting that change I noted? It feels like the only thing you changed that can have runtime effect.
there are actually more changes like that, basically all the removed parameters from @Body
if that wont help, i cant really help. i dont do webapps anymore, i don't use nest, and i never used swagger either.
also i don't consider this as something very important, this is an example app, its purpose is to show how to work with MikroORM and nest, not how to setup nest with swagger - that part is not that important. i would love to have it there, but its not a requirement really.
I'm just trying to learn using this app, since it's really short and simple. I found one more place to fix in e2e/Conduit.postman_collection.json
file, but even after that it keeps failing. What is the most strange is that I have the following error:
Register
POST https://conduit.productionready.io/api/users [422 Unprocessable Entity, 932B, 647ms]
But when I use Swagger UI I can't get such response at all, no matter what the input is: I get the HTTP 400 Bad Request instead with informative description.
I think what is happening here is really that newman is sending requests NOT to the localhost (the fact that I cannot hit any debug breakpoint kind of confirms this version). I guess this script is not testing the local project, it is testing something else instead.
I see your point of "just revert it back if it works", but I really don't like the nested approach of { "user": { "username": ..., "email": ..., "password": ... } }
because that makes writing @ApiBody() annotation difficult and the annotation itself ugly.
As for "why use the @ApiBody() annotation if it should work without it, when we use classes and not interfaces" - for some reason that just doesn't work for me.
I think what is happening here is really that newman is sending requests NOT to the localhost (the fact that I cannot hit any debug breakpoint kind of confirms this version). I guess this script is not testing the local project, it is testing something else instead.
Sounds like you are doing something wrong, the e2e test suite fires queries to the local server. I can literally see the query logs on the app instance when I run the e2e test suite.
Should be just about yarn start
in one terminal and yarn test:e2e
in another.
Should be just about
yarn start
in one terminal andyarn test:e2e
in another.
Yes, that's exactly what I'm doing. Still no breakpoints are triggered when I run npm run start:debug
in the first terminal...
Then what is the purpose of https://conduit.productionready.io/api URL?
Then what is the purpose of conduit.productionready.io/api URL?
Where did you find it? I'd guess it's a default, and the yarn test:e2e
call overrides it via the APIURL
env var:
https://github.com/mikro-orm/nestjs-realworld-example-app/blob/master/package.json#L16
and the
yarn test:e2e
call overrides it via theAPIURL
env var:
No, it does not work that way. Direct command line argument has higher priority than the env var with the same name.
Again, the readme file in e2e folder says
To locally run the provided Postman collection against your backend, execute:APIURL=http://localhost:3000/api ./run-api-tests.sh
So in fact I was passing http://localhost:3000
or http://localhost:3000/api
directly to my PowerShell call, and it turns out that was correct. If I did not do it I had an error like "Connect error" or something link that.
It seems it's finally working now. The problem yesterday was I that forgot to add /api
to my API_URL, I guess. Also there is a 100% chance to get HTTP 400 Bad Request error on user register endpoint when the user from the previous test run in not deleted from the database, and the username for the test run is not random (I used a static one).
No, it does not work that way. Direct command line argument has higher priority than the env var with the same name.
Well, it does work that way on my end, as well as in the CI 🤷
The problem yesterday was I that forgot to add /api to my API_URL,
The env var is called APIURL
, not API_URL
. You need to pay more attention to the detail :]
Made POST body schemas actually work