You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@heron.apache.org by GitBox <gi...@apache.org> on 2021/09/15 20:17:54 UTC

[GitHub] [incubator-heron] surahman opened a new issue #3713: Extending the Kubernetes V1Controller Test Suite

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: commits-unsubscribe@heron.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



[GitHub] [incubator-heron] nwangtw commented on issue #3713: Extending the Kubernetes V1Controller Test Suite

Posted by GitBox <gi...@apache.org>.
nwangtw commented on issue #3713:
URL: https://github.com/apache/incubator-heron/issues/3713#issuecomment-920430681


   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
   > <https://github.com/apache/incubator-heron/issues/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>.
   >
   >
   


-- 
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: commits-unsubscribe@heron.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



[GitHub] [incubator-heron] surahman closed issue #3713: Extending the Kubernetes V1Controller Test Suite

Posted by GitBox <gi...@apache.org>.
surahman closed issue #3713:
URL: https://github.com/apache/incubator-heron/issues/3713


   


-- 
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: commits-unsubscribe@heron.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org