Extending the Kubernetes V1Controller Test Suite

[surahman]

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.

[nwangtw]

Sounds good to me~ Thanks!

…

On Wed, Sep 15, 2021 at 1:17 PM Saad Ur Rahman ***@***.***> wrote: *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. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#3713>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABQPBH4JJAFJO7WD6CAVLGTUCD5PNANCNFSM5EDHKEEQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.