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

Updates to RangeSources #670

Merged
merged 13 commits into from Oct 2, 2022
Merged

Updates to RangeSources #670

merged 13 commits into from Oct 2, 2022

Conversation

Michael1993
Copy link
Member

@Michael1993 Michael1993 commented Sep 26, 2022

Closes #671

Proposed commit message:

Make RangeSource annotations non-repeatable (#671 / #670)

RangeSource annotations were made repeatable for the
CartesianProductTest extension. With the removal of the old
extension, RangeSources should be non-repeatable again.

This commit also fixes a bug that threw an exception when multiple
ArgumentSources were present on a test with a RangeSource. Now only
multiple RangeSources are not permitted, other ArgumentSources are
accepted.

Closes: #671 
PR: #670

TODO:

  • Document limitation of using multiple RangeSource annotations with a single ParameterizedTest?
  • Add more tests

PR checklist

The following checklist shall help the PR's author, the reviewers and maintainers to ensure the quality of this project.
It is based on our contributors guidelines, especially the "writing code" section.
It shall help to check for completion of the listed points.
If a point does not apply to the given PR's changes, the corresponding entry can be simply marked as done.

Documentation (general)

  • There is documentation (Javadoc and site documentation; added or updated)
  • There is implementation information to describe why a non-obvious source code / solution got implemented
  • Site documentation has its own .adoc file in the docs folder, e.g. docs/report-entries.adoc
  • Site documentation in .adoc file references demo in src/demo/java instead of containing code blocks as text
  • Only one sentence per line (especially in .adoc files)
  • Javadoc uses formal style, while sites documentation may use informal style

Documentation (new extension)

  • The docs/docs-nav.yml navigation has an entry for the new extension
  • The package-info.java contains information about the new extension

Code

  • Code adheres to code style, naming conventions etc.
  • Successful tests cover all changes
  • There are checks which validate correct / false usage / configuration of a functionality and there are tests to verify those checks
  • Tests use AssertJ or our own PioneerAssert (which are based on AssertJ)

Contributing

  • A prepared commit message exists
  • The list of contributions inside README.md mentions the new contribution (real name optional)

Bukama and others added 4 commits September 23, 2022 00:14
The CartesianTest extension was reimplemented in #487.
At the same time v1 was marked as deprecated and for
removal in Pioneer 2.0.

This PR removes this deprecated version.

Closes: #517
PR: #635
The Locale constructor is deprecated as of Java 19. Therefore, we
replace it by the `Locale.Builder`, which now does syntax checking.

Closes: #658
PR: #662
Starting with release 2.0 Pioneer sets Java 11 as it's base Java version.
With this PR only the build is updated to 11 without any further code
changes to create the new base first.

related #617
PR: #627
Copy link
Member

@aepfli aepfli left a comment

Choose a reason for hiding this comment

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

lgtm

@Michael1993 Michael1993 added the full-build Triggers full build suite on PR label Sep 26, 2022
@Michael1993
Copy link
Member Author

No automated checks? 😭

@aepfli
Copy link
Member

aepfli commented Sep 26, 2022

No automated checks? sob

strange actually the branch should be covered within

# Each pull request is important to us, doesn't matter from which branch.
# Furthermore, we do not want to build on just the default GitHub Action
# events, we also want to react onto `labeled` events for our extended
# build execution
pull_request:
branches: '*'
types: [labeled, opened, synchronize, reopened]

maybe we remove the branches directive as it is redundant anyways, see https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#running-your-workflow-based-on-the-head-or-base-branch-of-a-pull-request

// EDIT: looks like we do have a bug in the yml and it should be actually **

@Bukama
Copy link
Member

Bukama commented Sep 26, 2022

// EDIT: looks like we do have a bug in the yml and it should be actually **

I checked that in history, but it has always be single star. I opened #673 for the bug (to don't have it mixed with this PR)

Copy link
Member

@Bukama Bukama left a comment

Choose a reason for hiding this comment

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

Looks good. I checked docs and there is no way about repeatable annotation. Maybe we should add a sentence or two?

@Michael1993
Copy link
Member Author

Looks good. I checked docs and there is no way about repeatable annotation. Maybe we should add a sentence or two?

There was documentation about this feature in the deprecated @CartesianProductTest documentation, I believe? Where else would you like this documented (especially considering we are removing this functionality)?

@Bukama
Copy link
Member

Bukama commented Sep 26, 2022

Looks good. I checked docs and there is no way about repeatable annotation. Maybe we should add a sentence or two?

There was documentation about this feature in the deprecated @CartesianProductTest documentation, I believe? Where else would you like this documented (especially considering we are removing this functionality)?

I was thinking about explicity say, that it is not repeatable anymore (as it was in the old one). Like some kind of migration guide note.

@Michael1993
Copy link
Member Author

Michael1993 commented Sep 28, 2022

Looks good. I checked docs and there is no way about repeatable annotation. Maybe we should add a sentence or two?

There was documentation about this feature in the deprecated @CartesianProductTest documentation, I believe? Where else would you like this documented (especially considering we are removing this functionality)?

I was thinking about explicity say, that it is not repeatable anymore (as it was in the old one). Like some kind of migration guide note.

From a practical standpoint, it was never repeatable in the RangeSource context because the RangeSource extension throws an ExtensionConfigurationException if there is more than one RangeSource on a method, so I don't think that has to be documented for migration.

See https://github.com/junit-pioneer/junit-pioneer/pull/670/files#diff-2f3bbe470c2beba66f0fcc6bd6762f14828f9c966879622ff35b140c293a96eeR77

@Bukama
Copy link
Member

Bukama commented Sep 30, 2022

Please provide a commit message, so we can merge / close this :)

@Michael1993 Michael1993 merged commit e309be7 into lab/2.0 Oct 2, 2022
@Michael1993 Michael1993 deleted the lab/range-sources-2 branch October 2, 2022 14:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
full-build Triggers full build suite on PR
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants