Closed victorperin closed 4 years ago
I'm into it, but I have a couple of questions. The last two integration tests are not actually passing when you fix the described issue. Should I also fix them in the same PR, or should I just ignore them for the time being?
The problem is that by fixing those, the unit tests for scanFromFile
start to fail.
The reason for that is that the scanFromFile
tests assume it will just bubble up whatever error message it receives from its dependencies, whereas the integration tests assume they will have nice formatted messages (described in the ERROR
constant).
Would love to have your input here :)~
Feel free to check the current state of the branch here: https://github.com/Yurickh/qr-scanner-cli/tree/fix-async-tests
Yes, we noticed it when I was testing the other PR. Please, let them fail (because they already are). I'm working on a way to fix them.
I'm not sure if I understood correctly, but I can't create commits with failing tests due to the pre-commit hooks. I see six possible ways going forward:
scanFromFile
, so it just throws when errors. execution
would be the one handling errors. That makes it possible to keep integration tests with custom messages, and removes the need for the error tests in the unit tests for scanFromFile
, adding them to execution
instead;What's your take on this? :)~
Hey @Yurickh, thanks for remind me of those hooks.
This is my opinion, but feel free to do what you think is the best.
--no-verify
on commit command)scanFromFile
, to a new file, inside CLI folder. (to prevent making execution
file too complex.)Opened the PR with the failing tests, as suggested :)~
Reopened because pr automatically closed this issue.
Arguably the "some integration tests are passing without any assertion" has been fixed, since now they're failing 😅 Usually, I would open another issue with the description of the mismatch of the logging, so whoever takes it will have more context to fix it.
Finnaly fixed. :)
I noticed some integration tests are not being executed until end (mostly when you must trow an error or something like that).