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

Engineering: Custom Configs for Testing #23777

Open
eleanorjboyd opened this issue Jul 9, 2024 · 0 comments
Open

Engineering: Custom Configs for Testing #23777

eleanorjboyd opened this issue Jul 9, 2024 · 0 comments
Assignees
Labels
area-testing needs PR Ready to be worked on needs proposal Need to make some design decisions

Comments

@eleanorjboyd
Copy link
Member

eleanorjboyd commented Jul 9, 2024

This is a meta-issue tracking the variety of engineering related work on this proposal #21845 for custom args in testing.

Current status: basic MVP of features has been created in a prototype for test.

To Do Items:

  • get test config environment variables to work with debugging
  • support env file argument in settings.json config
  • remove params from launch.json that aren't possible to be put for a test debug config
  • put all new commands about configurations in the command palette
  • handle pytest detection to make extension reactive to the current user environment
  • switch off of the python.testing.pytestArgs and python.testing.pytestEnabled settings

Outstanding Bugs:

  • test config env vars not working in debugging
  • when a user deletes a discovery config, that test explorer tree does not get removed until a full reload

Outstanding Questions:

  • to confirm, the python path environment variable defined by the user in the settings.json config is appended to the python path and should not fully replace that path right?
  • How will we handle settings sync with configs?
  • Can users set these configs in their user settings? What would this mean?
  • Can a user have duplicate arguments in their settings.json and launch.json? If not how can we add a restriction or surface this?
  • Do we want framework in the individual configs? Do we want it set at a workspace level? How does switching between configs with different frameworks go? (frameworks being pytest and unittest)
  • Given that discovery configs create a different test tree in the explorer with their own buttons, when discovery configs >2 should those run buttons use their correlated config or the default?
  • What are we calling these? Configs? Profiles? How do we differentiate between the simplest test config and the default test profile as defined by the testing API.
  • When creating a new config (like from the Manage Test Configs menu) should we ask framework or assume?

Multiroot scenario:

We are still in the beginning stages of exploring multiroot for this project. The MVP looks better than expected but still have bugs / questions

bugs:

  • when you run a config from a given workspace B it will run that config across all workspaces and their tests
  • when you create configs in workspace A then B, only those in B show up in the dropdown
  • configs are not clearly associated with a workspace

outstanding questions:

  • How does it work to create configs across workspaces?
  • How should the test tree look in the explore panel? Will it include all roots, just the currently active one?
  • When using the run button menu will this always prompt for the workspace? (rn it is yes and I think that is a good way to go)
@eleanorjboyd eleanorjboyd added area-testing needs proposal Need to make some design decisions needs PR Ready to be worked on labels Jul 9, 2024
@eleanorjboyd eleanorjboyd added this to the July 2024 milestone Jul 9, 2024
@eleanorjboyd eleanorjboyd self-assigned this Jul 9, 2024
@karthiknadig karthiknadig modified the milestones: July 2024, August 2024 Jul 22, 2024
@karthiknadig karthiknadig removed this from the September 2024 milestone Sep 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-testing needs PR Ready to be worked on needs proposal Need to make some design decisions
Projects
None yet
Development

No branches or pull requests

2 participants