surahman opened a new issue #3713: URL: https://github.com/apache/incubator-heron/issues/3713
**Is your feature request related to a problem? Please describe.** There is little to no coverage of the code within the Kubernetes `V1Controller` class. To be able to add and augment features to the `V1Controller` we must ensure that we do not break existing functionality and that all code, old and new, is fully covered with tests. **Describe the solution you'd like** There is a basic test suite setup under `heron/schedulers/tests/java/org/apache/heron/scheduler/kubernetes/V1ControllerTest.java` in a WIP PR which needs to be extended for 100% code coverage of the entire class. The major issue with testing this class is the `private` scoping of the methods, but this constraint can be overcome using Java `Reflections`. There is an example in the WIP PR on how to achieve this. A lot of the statements within the methods go fairly deep into various other classes and it is infeasible to generate a fully populated `Config` object to satisfy the requirements. I encountered a number of null pointer exceptions, some of which were drilled down into file reads. I feel like the best way to handle testing the methods in the `V1Controller` class is to approach each method individually and mock (`mockito`) the calls to methods outside the class. I have created a `checkPodTemplateConfigMap` method in the test suite to test the output of the Pod Template `ConfigMap` volume mounting. This was done to permit a check of whether the statements added to include the `ConfigMap` were correctly executed within `createStatefulSet`. The correct way of handling this would be to setup a mock test that checks to see if the `podTemplateConfigMapName` is called within `createStatefulSet`. It is unnecessary to check if the `ConfigMap` is correct here as there is already an isolated test for it. It would be prudent to refactor the `checkPodTemplateConfigMap` into `testPodTemplateConfigMapVolume` once a mock of `createStatefulSet` is completed. **Describe alternatives you've considered** I have tried to generate fully populated `Config` Objects to try and satisfy the requirements to use simple JUnit tests to no avail. **Additional context** There is little to no test coverage of this class as it is right now. If things can break, they will break. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
