Skip to content
This repository has been archived by the owner on Sep 10, 2022. It is now read-only.

Add packager Controller Tests #133

Merged
merged 8 commits into from
Aug 25, 2020
Merged

Conversation

sladyn98
Copy link
Contributor

@sladyn98 sladyn98 commented Aug 14, 2020

This PR adds controller tests for the package generation controller. We already have the package generation class unit tested so this class only makes sure the file is being downloaded and generated correctly

@sladyn98 sladyn98 requested a review from a team as a code owner August 14, 2020 10:36
@sladyn98 sladyn98 changed the title WIP: Add packager Controller Tests Add packager Controller Tests Aug 16, 2020
Copy link
Contributor

@martinda martinda left a comment

Choose a reason for hiding this comment

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

These are high level tests. I would prefer to see low level unit tests for methods of each class, IMO it would be easier to review and easier to maintain, specifically unit tests for WarGenerator and PackagerDownloadService. Please provide unit tests for those classes.

Copy link
Contributor

@kwhetstone kwhetstone left a comment

Choose a reason for hiding this comment

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

Left some comments that can be addressed with Martin's review

@sladyn98
Copy link
Contributor Author

These are high level tests. I would prefer to see low level unit tests for methods of each class, IMO it would be easier to review and easier to maintain, specifically unit tests for WarGenerator and PackagerDownloadService. Please provide unit tests for those classes.

As mentioned previously running war generator inside JUNIT results in a lot of dependency issues Oleg tried to resolve some of them but they continued to persist. Hence we cannot write unit tests for these methods

private final static Logger LOGGER = Logger.getLogger(PackagerController.class.getName());

@Autowired
public PackagerController(final PackageConfigGenerator packageConfGen, final PackagerDownloadService packagerDownServ) {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Needed to autowire this in order for it to be mocked so that it gets dependency gets injected during testing.

@@ -47,7 +55,7 @@
String yamlResponse = "";
HttpStatus httpStatus;
try {
yamlResponse = generatePackageConfig(new JSONObject(postPayload));
yamlResponse = packagerConfGen.generatePackageConfig(new JSONObject(postPayload));
Copy link
Contributor Author

Choose a reason for hiding this comment

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

PMD complained with short names :)

@@ -0,0 +1 @@
This will serve as the dummy war file.
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Added a text file because the jacoco plugin errored out for dummy war files

@@ -29,23 +31,26 @@ public void setup() {
@Test
public void return_status_200() throws Exception {

MockMvc pluginMvc = MockMvcBuilders.webAppContextSetup(webApplicationContext).build();
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Maven was returning null on running these tests since the web app context was not available in the @before annotation, so injected it in the test.

@sladyn98 sladyn98 linked an issue Aug 23, 2020 that may be closed by this pull request
Copy link
Contributor

@martinda martinda left a comment

Choose a reason for hiding this comment

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

Please clean up the class and test method names:

  1. PackageControllerTest.java: must match the Java class name it tests (PackagerController.java)
  2. Test method names: it is best to match the methods they test in the class under test. Here is one example:
    1. Class under test method name: getPackageConfig, I expect to see a getPackageConfigTest method for the success path.
    2. For the error paths, expand on the name, for example: getPackageConfig404When<condition>
    3. When there are multiple error paths, there would be multiple test methods with different s

@martinda
Copy link
Contributor

The test methods cover all the conditions. This is good.

@@ -16,7 +16,7 @@
private static final String TEMP_PREFIX = "CDS";


public static File generateWAR(final String versionName, final String configuration) throws IOException, InterruptedException {
public File generateWAR(final String versionName, final String configuration) throws IOException, InterruptedException {
Copy link
Contributor

Choose a reason for hiding this comment

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

Just question: did you remove static to make it easier to test?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yes

@sladyn98 sladyn98 added the test A PR that adds to testing - used by Release Drafter label Aug 25, 2020
@sladyn98 sladyn98 merged commit 746fa5b into jenkinsci:master Aug 25, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
test A PR that adds to testing - used by Release Drafter
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Unit - Testing for all features
3 participants