-
-
Notifications
You must be signed in to change notification settings - Fork 403
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
WIP: Auto rules tests #2906
WIP: Auto rules tests #2906
Conversation
b369555
to
fa685d0
Compare
@aartaka The |
Yeah, that looks like no-rule -> no-rule transition, which currently unconditionally restores the last active modes over the enabled ones. |
I should've documented auto rules better 😰 |
Commits f22395b and e877455 fix an issue with I believe however that the fix belongs upstream. See fukamachi/quri#78. |
faa9f8e fixes the test before the last one. But
|
I've fixed it, I think. But I'll have to test it more. In the meantime, here's a full matrix of cases we have to test (with combinations that we currently have marked with names of tests including them):
But this framework is insufficient to describe all the scenarios. Additional situations to test too (and that current tests more or less manage):
|
Do we really need the renderer to test |
@aadcg For now, yes, because auto-rules are triggered by @aartaka Could we trigger auto-rules else where? Better:
|
@aartaka Great work with the matrix, I'll get down to it. |
@Ambrevar makes sense, thanks for the clarification! |
Note that not all the cases are a huge priority. I'd focus on include and exclude ones, possibly ignoring the include+exclude ones as a supposed subset of the former two. Some corner-cutting could be done too. Don't get burned out doing several dozens of tests :P |
A way to cut some corners: test all the page transitions with just one rule (like we are doing now), and then test all the rule types with some typical use scenario (like no-rule -> rule -> no-rule transition). It's not exactly bullet-proof, but possible to implement fast and covers the most matrix space with least effort spent. |
(and url | ||
(or (null (last-active-modes-url buffer)) | ||
(not (quri:uri= url (last-active-modes-url buffer))) | ||
(not (matching-auto-rules (previous-url buffer) buffer))))) |
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.
Can you add a docstring to explain what this does?
@aartaka Can you also document:
|
See the new documentation in
See the updated docs and
I'm wondering if |
No cache is retained, so history is empty again on subsequent run.
Indeed, Quri allows cl:pathname as path.
This ensures that all the cases with non-matching pages save/restore last-active-modes.
Two changes: - last-active-modes are saved if there was no previous rules. - And they are reapplied when going between two pages with rules.
75d3257
to
93aba2f
Compare
This is extremely weird. Test fails locally, but the interactive session works just fine (・_・ヾ |
What's the status here? |
Partially fixed on master, but needs more tests (and, supposedly, more fixes). |
What's the status here?
Partially fixed on master, but needs more tests (and, supposedly, more fixes).
|
I think this is not the right way of handling communication in a collaborative project. If you have merged a subset of commits featured in this PR, you should have informed about it beforehand in this thread. Then you should inform the parties involved about the future of this PR. Should it be closed, rebased, etc? Loose ends are enemies of a successful project.
What should we do about this PR? |
We need to finish it, as the tests (about mode exclusion) do not all pass. See comment #2906 (comment). |
Please reopen when ready. |
This PR personifies the kind of interaction we can't tolerate. See my comment above. The fact that auto rules was deployed without a test suite in the first place is also a bad practice. |
Description
This adds the long awaited auto-rules test. Since it's currently broken (see #2895), we are in urgent need of a test suite to validate the many edge cases.
Should help with #2895.
Discussion
Just a draft for now, there is much more to test.
Checklist:
Everything in this checklist is required for each PR. Please do not approve a PR that does not have all of these items.
cd /path/to/nyxt/checkout git submodule add https://gitlab.common-lisp.net/nyxt/py-configparser _build/py-configparser
:documentation
s written in the aforementioned style. (It's OK to skip the docstring for really trivial parts.)changelog.lisp
with my changes if it's anything user-facing (new features, important bug fix, compatibility breakage).migration.lisp
entry for all compatibility-breaking changes.(asdf:test-system :nyxt)
and(asdf:test-system :nyxt/gi-gtk)
) and they pass.