Skip to content
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

Closed
wants to merge 20 commits into from
Closed

WIP: Auto rules tests #2906

wants to merge 20 commits into from

Conversation

Ambrevar
Copy link
Member

@Ambrevar Ambrevar commented Apr 14, 2023

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.

  • Git hygiene:
    • I have pulled from master before submitting this PR
    • There are no merge conflicts.
  • I've added the new dependencies as:
    • ASDF dependencies,
    • Git submodules,
      cd /path/to/nyxt/checkout
      git submodule add https://gitlab.common-lisp.net/nyxt/py-configparser _build/py-configparser
    • and Guix dependencies.
  • My code follows the style guidelines for Common Lisp code. See:
  • I have performed a self-review of my own code.
  • My code has been reviewed by at least one peer. (The peer review to approve a PR counts. The reviewer must download and test the code.)
  • Documentation:
    • All my code has docstrings and :documentations written in the aforementioned style. (It's OK to skip the docstring for really trivial parts.)
    • I have updated the existing documentation to match my changes.
    • I have commented my code in hard-to-understand areas.
    • I have updated the changelog.lisp with my changes if it's anything user-facing (new features, important bug fix, compatibility breakage).
    • I have added a migration.lisp entry for all compatibility-breaking changes.
    • (If this changes something about the features showcased on Nyxt website) I have these changes described in the new/existing article at Nyxt website or will notify one of maintainters to do so.
  • Compilation and tests:
    • My changes generate no new warnings.
    • I have added tests that prove my fix is effective or that my feature works. (If possible.)
    • I ran the tests locally ((asdf:test-system :nyxt) and (asdf:test-system :nyxt/gi-gtk)) and they pass.

@Ambrevar
Copy link
Member Author

@aartaka The auto-rules-remembered-modes last 2 assertions are failing. In my understanding, this is an auto-rules bug. Could you look into it?

@aartaka
Copy link
Contributor

aartaka commented Apr 14, 2023

@aartaka The auto-rules-remembered-modes last 2 assertions are failing. In my understanding, this is an auto-rules bug. Could you look into it?

Yeah, that looks like no-rule -> no-rule transition, which currently unconditionally restores the last active modes over the enabled ones.

@aartaka
Copy link
Contributor

aartaka commented Apr 14, 2023

I should've documented auto rules better 😰

@Ambrevar
Copy link
Member Author

Commits f22395b and e877455 fix an issue with cl:pathname in quri:uri path.

I believe however that the fix belongs upstream. See fukamachi/quri#78.

@aartaka
Copy link
Contributor

aartaka commented Apr 19, 2023

faa9f8e fixes the test before the last one. But

  • the last test still fails,
  • and transitioning from rule-less page to rule-having one and then back makes the rule-toggled modes to be saved to last-active-modes. Investigating.

@aartaka
Copy link
Contributor

aartaka commented Apr 21, 2023

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):

| transition\rule    | exclude | include              | exclude+include |
| rule -> rule       |         |                      |                 |
| no rule -> no rule |         | remembered-modes + 1 |                 |
| rule -> no rule    |         | navigation... + 1    |                 |
| no rule -> rule    |         | basic                |                 |

But this framework is insufficient to describe all the scenarios. Additional situations to test too (and that current tests more or less manage):

  • Reloading the page (rule, no rule).
  • Manual mode toggling (same matrix).

@aadcg
Copy link
Member

aadcg commented Apr 21, 2023

Do we really need the renderer to test auto-rules?

@Ambrevar
Copy link
Member Author

@aadcg For now, yes, because auto-rules are triggered by on-signal-decide-policy.

@aartaka Could we trigger auto-rules else where?

Better:

  1. Either we should have a way to load pages without having to render them. But does WebKit allow this? If not, can we decouple resource loading from rendering?
  2. Tweak the dummy renderer to support "loading" HTML, fire on-signal-decide-policy, and thus trigger the auto-rules.

@Ambrevar
Copy link
Member Author

@aartaka Great work with the matrix, I'll get down to it.

@aadcg
Copy link
Member

aadcg commented Apr 24, 2023

@Ambrevar makes sense, thanks for the clarification!

@aartaka
Copy link
Contributor

aartaka commented Apr 24, 2023

@aartaka Great work with the matrix, I'll get down to it.

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

@aartaka
Copy link
Contributor

aartaka commented Apr 24, 2023

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)))))
Copy link
Member Author

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?

@Ambrevar
Copy link
Member Author

Ambrevar commented Apr 26, 2023

@aartaka Can you also document:

  • the logic behind top-level-p in gtk.lisp
  • save-last-active-modes
  • reapply-last-active-modes (which are the "last" active modes? Consider the case of matched rule and unmatched rule)
  • remember-on-mode-toggle: Why is save-last-active-modes called if prompt-on-mode-toggle-p is NIL and not in the other branch?
  • add-modes-to-auto-rules: Docstring including an example usage that involves url-infer-match and rememberable-of.

@Ambrevar
Copy link
Member Author

Commit 294b2c2 with mode exclusion fails. @aartaka Can you look into it?

@aartaka
Copy link
Contributor

aartaka commented Apr 27, 2023

  • the logic behind top-level-p in gtk.lisp

See the new documentation in toplevel-p slot of request-data.

  • save-last-active-modes
  • reapply-last-active-modes (which are the "last" active modes? Consider the case of matched rule and unmatched rule)
  • remember-on-mode-toggle: Why is save-last-active-modes called if prompt-on-mode-toggle-p is NIL and not in the other branch?

See the updated docs and last-active-modes slot documentation.

  • add-modes-to-auto-rules: Docstring including an example usage that involves url-infer-match and rememberable-of.

I'm wondering if url-infer-match should actually be part of add-modes-to-auto-rules...

@aartaka
Copy link
Contributor

aartaka commented Apr 28, 2023

Commit 294b2c2 with mode exclusion fails. @aartaka Can you look into it?

Two of the failures were due to a typo (fixed in 6ec8133) :P

The third one... Not sure. Investigating.

@aartaka
Copy link
Contributor

aartaka commented May 1, 2023

This is extremely weird. Test fails locally, but the interactive session works just fine (・_・ヾ

@aadcg aadcg mentioned this pull request May 2, 2023
aadcg referenced this pull request May 9, 2023
@aadcg
Copy link
Member

aadcg commented May 9, 2023

What's the status here?

@aartaka
Copy link
Contributor

aartaka commented May 9, 2023

Partially fixed on master, but needs more tests (and, supposedly, more fixes).

@aartaka
Copy link
Contributor

aartaka commented May 9, 2023 via email

@aadcg
Copy link
Member

aadcg commented May 9, 2023

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.


Partially fixed on master, but needs more tests (and, supposedly, more fixes).

What should we do about this PR?

@Ambrevar
Copy link
Member Author

We need to finish it, as the tests (about mode exclusion) do not all pass. See comment #2906 (comment).

@jmercouris
Copy link
Member

Please reopen when ready.

@jmercouris jmercouris closed this Oct 28, 2023
@aadcg
Copy link
Member

aadcg commented Oct 30, 2023

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.

@aadcg aadcg deleted the auto-rules-tests branch October 30, 2023 20:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants