Skip to content

Conversation

evetion
Copy link
Contributor

@evetion evetion commented Jun 19, 2025

Fixes #110

Copy link

codecov bot commented Jun 19, 2025

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.07%. Comparing base (5f695db) to head (ed53fcc).
⚠️ Report is 5 commits behind head on main.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #111   +/-   ##
=======================================
  Coverage   93.07%   93.07%           
=======================================
  Files           2        2           
  Lines         130      130           
=======================================
  Hits          121      121           
  Misses          9        9           
Flag Coverage Δ
unittests 93.07% <100.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@davidanthoff
Copy link
Member

Hm, I guess the question is whether it makes sense to have that as an option for just the command line runner? Presumably you would also want the custom testset used when running in VS Code?

This generally strikes me as a global setting, and what we really need is a way to configure global settings...

@evetion
Copy link
Contributor Author

evetion commented Jun 22, 2025

Hm, I guess the question is whether it makes sense to have that as an option for just the command line runner? Presumably you would also want the custom testset used when running in VS Code?

This generally strikes me as a global setting, and what we really need is a way to configure global settings...

For my use case this makes sense, as I want a custom runner for a specific (headless) CI environment. In VS Code I'm fine with the default runner. I could also make a PR on top of this configuring it for a specific testitem, not unlike how @testset takes the custom argument? That should work in both modes?

@davidanthoff
Copy link
Member

Ok, I think if this is actually a setting that makes sense not as a permanent property of the test items, but for certain test run environments, then this is actually the right way to implement it!

- `verbose`: Whether to run the tests in verbose mode.
"""
function run_tests(path; filter=nothing, verbose=false)
function run_tests(path; filter=nothing, verbose=false, testset=testset)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not yet fully implemented, right? Value here is never used, and the default argument not defined?

Copy link
Contributor Author

@evetion evetion Jun 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@davidanthoff It is, testset is used on line 197,199,220, and defined on line 268.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@davidanthoff Friendly bump

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

Successfully merging this pull request may close these issues.

Allow custom testset for all package tests
3 participants