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

Better docs/typing support from pythonlib-juju objects #83

Open
marcoppenheimer opened this issue Jun 23, 2022 · 0 comments
Open

Better docs/typing support from pythonlib-juju objects #83

marcoppenheimer opened this issue Jun 23, 2022 · 0 comments

Comments

@marcoppenheimer
Copy link

Request

  • Provide a way that we can better rely on pythonlib-juju's signatures to help writing int tests. Ideally would like to rely on pytest-operator and not another library that is wrapped by it
    • Maybe by exposing a slightly safer ops_test.model/unit/app with some supported usage examples?
  • The reference docs for pytest-operator are REALLY hard to read, and it's very easy to miss things, could these be improved in a more readable / less manual format?

Issue

  • When developing integration tests, the current typing implementation doesn't support peeking (in my case, vim.lsp.buf.signature_help() using pyright as the LSP)

  • This is because of 'challenging' typing from pythonlib-juju

  • Although tightening up that typing is out of the scope for pytest-operator, the common workflow building int tests looks like:

    • Type ops_test.model or ops_test.model.applications
    • Go to the pythonlib-juju source code
    • Hope you find a usefully named method/attr by scouring the source for juju.applications, juju.unit, juju.model etc (often which does not have types)
    • Experiment with returned instances with some combination of vars(questionable_object) or dir(questionable_object), all of which takes a lot of time and trial-and-error that don't belong in test-writing
  • Overall, this makes building integration tests really slow, and more likely to blindly copy code from other examples of charm repos that have done the work already. Not bad on it's own, but probably undesirable.

Examples

Wall of error messages with Pyright

Blinding error messages

Returned attrs unpeekable

Non-peekable units

Hard-to-parse References render in GH

GH references render being hard-to-parse

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

No branches or pull requests

1 participant