Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Improve logarithmic quantity tests parametrization #18473

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.

Sign up for GitHub

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

Jump to bottom
Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Improve logarithmic quantity tests parametrization #18473

wants to merge 1 commit into from
+44 −46

Conversation

eerovaher
Copy link
Member

Description

I am replacing several for-loops inside logarithmic quantity tests with parametrized tests. These are better than for-loops inside tests because a parameter that causes a test to fail does not prevent other parameters from being tested. Furthermore, the output of pytest is much better if a test fails or if pytest is invoked with the --verbose option. In this particular case defining a module level decorator for parametrization also allows eliminating two test class setup methods.

  • By checking this box, the PR author has requested that maintainers do NOT use the "Squash and Merge" button. Maintainers should respect this when possible; however, the final decision is at the discretion of the maintainer that merges the PR.

@eerovaher
Improve logarithmic quantity tests parametrization
0aa15c8 
Using `pytest.mark.parametrize()` is better than having a `for`-loop
inside a test. One parameter causing a test failure does not prevent
other parameters from being tested. Furthermore, the output of `pytest`
is much better if a test fails or if `pytest` is invoked with the
`--verbose` option.
@eerovaher eerovaher added this to the v7.2.0 milestone Jul 29, 2025
@eerovaher eerovaher requested a review from mhvk July 29, 2025 20:53
@github-actions GitHub Actions
Copy link
Contributor

Thank you for your contribution to Astropy! 🌌 This checklist is meant to remind the package maintainers who will review this pull request of some common things to look for.

  • Do the proposed changes actually accomplish desired goals?
  • Do the proposed changes follow the Astropy coding guidelines?
  • Are tests added/updated as required? If so, do they follow the Astropy testing guidelines?
  • Are docs added/updated as required? If so, do they follow the Astropy documentation guidelines?
  • Is rebase and/or squash necessary? If so, please provide the author with appropriate instructions. Also see instructions for rebase and squash.
  • Did the CI pass? If no, are the failures related? If you need to run daily and weekly cron jobs as part of the PR, please apply the "Extra CI" label. Codestyle issues can be fixed by the bot.
  • Is a change log needed? If yes, did the change log check pass? If no, add the "no-changelog-entry-needed" label. If this is a manual backport, use the "skip-changelog-checks" label unless special changelog handling is necessary.
  • Is this a big PR that makes a "What's new?" entry worthwhile and if so, is (1) a "what's new" entry included in this PR and (2) the "whatsnew-needed" label applied?
  • At the time of adding the milestone, if the milestone set requires a backport to release branch(es), apply the appropriate "backport-X.Y.x" label(s) before merge.

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

@mhvk mhvk Awaiting requested review from mhvk

At least 1 approving review is required to merge this pull request.

Assignees
No one assigned
Labels
no-changelog-entry-needed testing units
Projects
None yet
Milestone
v7.2.0
Development

Successfully merging this pull request may close these issues.
1 participant
@eerovaher