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

Refactor API tests to using JUnit5 + custom extensions #8251

Open
poikilotherm opened this issue Nov 22, 2021 · 0 comments
Open

Refactor API tests to using JUnit5 + custom extensions #8251

poikilotherm opened this issue Nov 22, 2021 · 0 comments

Comments

@poikilotherm
Copy link
Contributor

poikilotherm commented Nov 22, 2021

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:

  1. refactor API tests from JUnit 4 to JUnit 5
  2. create custom extensions to handle things like database settings, creation of resources
  3. prepare the test code to be reusable with Testcontainers in Increase testability by using Testcontainers #8250

What kind of user is the feature intended for?
(Example users roles: API User, Curator, Depositor, Guest, Superuser, Sysadmin)

  • Developer
  • (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?

  1. Move all *IT.java used in regular integration tests to JUnit5
  2. Create JUnit 5 extensions for most important tasks (DB settings, resource creation)
  3. Document this stuff in a dev guide section on how to write API tests
  4. Update RESTassured from v2.4 to latest v4.4

Any 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

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
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant