-
Notifications
You must be signed in to change notification settings - Fork 489
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
Refactor API tests to using JUnit5 + custom extensions #8251
Comments
poikilotherm
added a commit
to poikilotherm/dataverse
that referenced
this issue
Nov 22, 2021
poikilotherm
added a commit
to poikilotherm/dataverse
that referenced
this issue
Nov 22, 2021
This will allow for a standardized collection of Strings thus avoid typos
poikilotherm
added a commit
to poikilotherm/dataverse
that referenced
this issue
Nov 22, 2021
This extension allows to set and reset database settings within a target Dataverse instance. It will make sure to reset to old setting or remove the setting if not set before the test. This was introduced for three reasons: 1. Don't execute a test if the setting did not go through 2. Don't forget to reset or remove to keep a consistent state after a test execution 3. Make the code more readable, as setting the setting has been part of the test before (which is bad design and might go booboo, see 2)
poikilotherm
added a commit
to poikilotherm/dataverse
that referenced
this issue
Nov 22, 2021
poikilotherm
added a commit
to poikilotherm/dataverse
that referenced
this issue
Nov 22, 2021
…IQSS#8251 When no stored procedure has been set up in the instance under test, test running after DatasetsIT.testStoredProcGeneratedAsIdentifierGenerationStyle() failed, as the database setting was never reverted. Making use of the new @DBSetting extension helps with that.
poikilotherm
added a commit
to poikilotherm/dataverse
that referenced
this issue
Nov 22, 2021
poikilotherm
added a commit
to poikilotherm/dataverse
that referenced
this issue
Nov 22, 2021
…IQSS#8251 When no stored procedure has been set up in the instance under test, test running after DatasetsIT.testStoredProcGeneratedAsIdentifierGenerationStyle() failed, as the database setting was never reverted. Making use of the new @DBSetting extension helps with that.
poikilotherm
added a commit
to poikilotherm/dataverse
that referenced
this issue
Nov 30, 2021
Many API tests require the use of a random user, which is no SuT (subject under test). To gather such a user and ensure its deletion from a target Dataverse instance after a test, this extension provides a convenient way. Simple use ExtendWith and provide a RandomUser parameter, you're done.
poikilotherm
added a commit
to poikilotherm/dataverse
that referenced
this issue
Nov 30, 2021
With this commit, the RandomUserExtension may be used on a test class, @BeforeEach/All, @AfterEach/All methods and test methods. It will take care of deletion in the appropriate ways to ensure a healthy target environment. Using it on @AfterEach/All will return the formerly created user via @BeforeEach/All and enabled aftermath reuse of the user.
poikilotherm
added a commit
to poikilotherm/dataverse
that referenced
this issue
Nov 30, 2021
With this commit, the RandomUserExtension may be used on a test class, @BeforeEach/All, @AfterEach/All methods and test methods. It will take care of deletion in the appropriate ways to ensure a healthy target environment. Using it on @AfterEach/All will return the formerly created user via @BeforeEach/All and enabled aftermath reuse of the user.
poikilotherm
added a commit
to poikilotherm/dataverse
that referenced
this issue
Nov 30, 2021
Many API tests require the use of a random user, which is no SuT (subject under test). To gather such a user and ensure its deletion from a target Dataverse instance after a test, this extension provides a convenient way. Simple use ExtendWith and provide a RandomUser parameter, you're done.
poikilotherm
added a commit
to poikilotherm/dataverse
that referenced
this issue
Nov 30, 2021
With this commit, the RandomUserExtension may be used on a test class, @BeforeEach/All, @AfterEach/All methods and test methods. It will take care of deletion in the appropriate ways to ensure a healthy target environment. Using it on @AfterEach/All will return the formerly created user via @BeforeEach/All and enabled aftermath reuse of the user.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Overview of the Feature Request
While hacking on code for #8250 I noticed some problems due to how API tests are currently done: creating collections, datasets, users and settings is mostly done within the test code itself.
This request is a request to:
What kind of user is the feature intended for?
(Example users roles: API User, Curator, Depositor, Guest, Superuser, Sysadmin)
What inspired the request?
Some tests failed when working on #8250 because of formerly unexpressed dependencies on setup and settings. As a root cause it became clear that a failing test not resetting a database setting can render other tests to fail.
This can be avoided by creating extensions that hook into the test lifecycles when necessary (
@Before
/@After
is not flexible enough here!) and ensure settings are present (set if not not) and clean up after the test, independent of the outcome. This is MUCH easier with JUnit 5 than 4 (the successor has been designed exactly with this in mind), thus a small refactoring is necessary to move to 5.The test code would also become much more readable when the repetitive task of creating test users, test collections and test datasets would not have to be repeated code within almost every test routine. Also leaving an inconsistent state when tests fail, as the cleanup is a part of the test.
What existing behavior do you want changed?
*IT.java
used in regular integration tests to JUnit5Any brand new behavior do you want to add to Dataverse?
Not to application behaviour.
Any related open or closed issues to this feature request?
#8250
The text was updated successfully, but these errors were encountered: