-
Notifications
You must be signed in to change notification settings - Fork 0
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
Cracks #99
base: master
Are you sure you want to change the base?
Conversation
The cracks failure should be at least in part due to the fact that the tests are relying on setting/changing variables manually, rather than just calling the APIs. It's quite possible that there were breaking changes in addition to this. However, I assume tests should not be directly setting variables (e.g. |
@sam1463 I agree so long as the variables are never changed by hand by consumers of the library. If they are, then it's definitely something that we want to test. If they don't, then the tests should be changed to reflect the API usage instead of modifying private fields directly (calling the functions that the user would call to change those fields). I would have to sit down more with the cognitive-lib to understand its API to make that call myself, but would be happy to do so if that is needed. |
Just spoke with Jorge, and he agrees that the initializer is what should actually be called, and that libraries using cog-lib are only setting variables using the initializer, not changing them on the fly. So I think in this specific case, we should be making the tests rely only on the initializer and the APIs, since that's all that users are using, so changing variables manually is testing implementation and not a real use case. To go about changing issues like this, should we first make a PR to change the tests to not rely on implementation, that way cracks won't fail since the functionality doesn't fail, then make a new PR to change the functionality, and the new PR would also not fail since cracks would check against the new tests, not the old ones? |
In this specific situation since we haven't fully ironed out how we are going to work Sorry if my above message was confusing. |
Changes Unknown when pulling 4c44cad on cracks into * on master*. |
A potential API Breaking change was found in this PR:
|
A potential API Breaking change was found in this PR:
|
Changes Unknown when pulling 780c0bb on cracks into * on master*. |
this would be the minimum viable
cracks
integration, the build should fail when cracks detects that the tests associated with our last release are failing against the current code base.Failing tests may be (on occasion) a false positive, but it is better to be safe than sorry. Tests should be testing the API and not the implementation anyway, which would be the biggest cause of false positives using this tool.
In general, it is easy to think about API breaking changes in relation to tests:
It looks like we may have caught a breaking change around the
rrManager
stuff as this build is failing due tocracks
.