-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[AzureDevOpsTests] Refactor unit tests to improve stability #2454
Conversation
Generated by 🚫 dangerJS |
Hi! Thanks so much for responding to this. The reason It's fine to add mock tests, though they should be in addition to the live tests. To fix the live tests, I'd suggest adding a new Joi matcher in this test file that includes "no tests" along with the other possible results. The reason we generally prefer live tests is because server APIs change and server behaviors can change in subtle ways we depend on. This way we often find out about the failures first. Sometimes it's the only way we find out at all, because issues aren't always reported. Yes, they're more work to maintain, though we get enough value out of them that it's worth it… and we're continually getting better at avoiding false positives. There's some background discussion on the strategy in #927. You mentioned in #2411 this was an undocumented API, so all the more reason to have our tests fail if something changes upstream… |
Updated mocked tests to use expected values for assertion. Added live tests to test the API. Added `no tests` as an acceptable result for live tests.
Hi @paulmelnikow! Thanks a lot for the detailed review, it now makes sense to keep an eye on the public APIs through unit tests. I switched the mocked tests to be asserted by expected preset values, and added live tests that are asserted dynamically using regex. I added Thanks again! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! This looks good, just one comment to avoid some repetition
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lovely, thank you.
As discussed in #2412, a failed build yielded a
no tests
badge. This is a valid scenario, but the unit tests that assert the badge message for different configurations were failing as they assumed a successful response that contains tests for live requests.This PR adds a mock response and corrects the RegEx logic used in the unit tests to mitigate this scenario and decouple from the live API.
/cc @paulmelnikow, @calebcartwright