Skip to content

Clean way to optional enable/disable extensions #25

Closed

Description

@asmeurer

Now that we are adding more tests for the linalg extension, and we will soon have other extensions as well, we need to have a clean way for modules to not implement these extensions and not fail the test suite. Some test files mix extension and non-extension tests, e.g., the signature tests currently test all signatures.

This is closely related to #20.

Activity

  1. honno commented on Oct 5, 2021

    @honno
    Member

    Bare minimum it would be nice if we automatically skipped tests if required attributes don't exist, like:

    @pytest.mark.skipif(not hasattr(xp, "linalg")), reason="extension not found")

    This could be a more immediate thing we do. Could be refactored to something like mark.requires_xp_linalg. We could create a custom option and use a hook in conftest.py down the line if we think its still useful to folks.


    Side note: If we're interested in tracking the dependencies of the array module generally, EVERY test method could have something like mark.xp_deps([<attr names>]). We could can play around with pytest's collection to prioritise low dep things first, and automatically skip tests which are using faulty, more-"atomic" methods. e.g.:

    @pytest.mark.xp_deps(["all", "equal"])
    def test_foo(...):
        ...
        assert xp.all(...)
        assert xp.equal(...)

    This would probably be too much of a headache, but something I'd consider in the future when this test suite is otherwise "complete". Good exercise for us to track dependencies too.

    EDIT: I now realise this idea is particularly awkward as it'll need to declare dependencies on array object behaviour too. Also I see now with your recent comment that array_helpers.py already encourages limited deps.

  2. honno commented on Oct 12, 2021

    @honno
    Member

    pytest.param() also allows us to specify marks, so linalg-related parameters in test_signatures.py could share the same marks we might use for all the linalg tests.

  3. asmeurer commented on Oct 12, 2021

    @asmeurer
    MemberAuthor

    Is the set of active marks accessible from inside the test functions? It might be necessary to have branching logic in the test itself.

  4. honno commented on Oct 13, 2021

    @honno
    Member

    Is the set of active marks accessible from inside the test functions? It might be necessary to have branching logic in the test itself.

    Can't think of a way to do that myself. I suppose you could send marks as parameters and as the marks meta, i.e. param(..., marks, marks=marks).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions