Experimental way of testing HubController api endpoint call

[CDellaGiusta]

What does this PR change?

EXPERIMENTAL!

The aim is to test a HubController API call without actually setting up a remote server and using tools like postman.
The idea is that unit tests can be done to test the behaviour and the returned values, while a single manual test can be done from the external (e.g. postman) to check that the API endpoint is really visible.

In this test I tried to test the /hub/managerinfo API endpoint, and of course I will use the testing environment to build and test the APIs that are still missing.

Although I guess I will be expanding the way things are tested, I'd like somebody else to have a look at it to see if I'm on the right track before proceeding further on this road. All comments and suggestions are extremely welcome.

GUI diff

• DONE

Documentation

• No documentation needed: experimental
• DONE

Test coverage

• Unit tests were added
• DONE

Links

• DONE

Changelogs

• No changelog needed

Re-run a test

• Re-run test "changelog_test"
• Re-run test "backend_unittests_pgsql"
• Re-run test "java_pgsql_tests"
• Re-run test "schema_migration_test_pgsql"
• Re-run test "susemanager_unittests"
• Re-run test "javascript_lint"
• Re-run test "spacecmd_unittests"

[github-actions]

👋 Hello! Thanks for contributing to our project.
Acceptance tests will take some time (aprox. 1h), please be patient ☕
You can see the progress at the end of this page and at https://github.com/uyuni-project/uyuni/pull/9704/checks
Once tests finish, if they fail, you can check 👀 the cucumber report. See the link at the output of the action.
You can also check the artifacts section, which contains the logs at https://github.com/uyuni-project/uyuni/pull/9704/checks.

If you are unsure the failing tests are related to your code, you can check the "reference jobs". These are jobs that run on a scheduled time with code from master. If they fail for the same reason as your build, it means the tests or the infrastructure are broken. If they do not fail, but yours do, it means it is related to your code.

Reference tests:

• https://github.com/uyuni-project/uyuni/actions/workflows/acceptance_tests_secondary_parallel.yml?query=event%3Aschedule

• https://github.com/uyuni-project/uyuni/actions/workflows/acceptance_tests_secondary.yml?query=event%3Aschedule

KNOWN ISSUES

Sometimes the build can fail when pulling new jar files from download.opensuse.org . This is a known limitation. Given this happens rarely, when it does, all you need to do is rerun the test. Sorry for the inconvenience.

For more tips on troubleshooting, see the troubleshooting guide.

Happy hacking!
⚠️ You should not merge if acceptance tests fail to pass. ⚠️

[github-actions]

Suggested tests to cover this Pull Request

[mcalmer]

@CDellaGiusta This looks good. I would implement this in a new class called HubControllerTest to not overload HubManagerTest and we are here testing the Controller. It might be also a good idea to put "simulateHubControllerApi" and "simulateApiEndpointCall" methods in a class called like ControllerTestUtils and make them public and document them.
I think in future we might get endpoints similar to /hub and they need to be tested as well. Having a TestUtils class which provide the utilities needed for this might be usefull. We can also check if something like already exists where we can put this things to.

[CDellaGiusta]

@mcalmer

We can also check if something like already exists where we can put this things to.
I decided to split the "simulation" test method in two parts

simulateHubControllerApi has all the dependencies to HubFactory and HubController
simulateApiEndpointCall has no such dependencies and so SparkTestUtils class could be a candidate class where to move this function. I expect there will be some instances of that with a non-null http request body etc.

If we decide to go for a separate ControllerTestUtils class, then we can keep these two methods in the same place.

Let's see what the others think

[rjmateus]

would be a option to use the route find method, which would be able to handle wildcard?
In the URL you could use the expected URL to be used (like: /systems/1000001/bla) which would math the route pattern like /systems/:ID/bla.
You can see an example in here: https://github.com/rjmateus/uyuni/blob/uyuni_hack_authorization_check/java/code/src/com/redhat/rhn/frontend/servlets/AccessFilter.java#L116-L118