You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@geode.apache.org by "Dale Emery (Jira)" <ji...@apache.org> on 2022/01/14 23:25:00 UTC

[jira] [Updated] (GEODE-9897) ClientUserAuthsTest leaves some seemingly tested responsibilities untested

     [ https://issues.apache.org/jira/browse/GEODE-9897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dale Emery updated GEODE-9897:
------------------------------
    Fix Version/s: 1.15.0

> ClientUserAuthsTest leaves some seemingly tested responsibilities untested
> --------------------------------------------------------------------------
>
>                 Key: GEODE-9897
>                 URL: https://issues.apache.org/jira/browse/GEODE-9897
>             Project: Geode
>          Issue Type: Test
>          Components: tests
>            Reporter: Dale Emery
>            Assignee: Dale Emery
>            Priority: Major
>              Labels: GeodeOperationAPI, pull-request-available
>             Fix For: 1.15.0
>
>
> *Problem 1:* The test class's {{before()}} method uses the {{spy()}} mechanism to override {{getNextId()}} on the {{ClientUserAuths}} it is testing. This bypasses the actual implementation for all tests, leaving untested the following important {{ClientUserAuths}} responsibilities:
>  - Detect when all IDs have all been used.
>  - Clear all existing authentications when all IDs have been used, to force reauthentication.
>  - Re-seed the ID generator when all IDs have been used.
> The tests are likely doing this because {{getNextId()}} relies on a {{{}Random{}}}, which is uncontrollable by design. Because {{ClientUserAuths}} creates the {{{}Random{}}}, the tests are unable to inject a testable instance, and so instead must bypass the {{ClientUserAuths}} methods that interact with the {{{}Random{}}}.
> The solution to this problem is to extract and test an ID generator that accepts a {{Random}} as a constructor parameter, thus allowing tests to control it.
> This also frees {{ClientUserAuths}} from the responsibility to generate IDs, so it can instead focus on how it uses the IDs. Then it will be straightforward to write tests to verify that {{ClientUserAuths}} forces reauthentication when the generator runs out of IDs.
> *Problem 2:* Several tests in this class attempt to verify certain responsibilities only by spying on how the {{ClientUserAuths}} interacts with itself. Verifying only these internal interactions leaves the actual responsibilities (how the {{ClientUserAuths}} responds to subsequent calls) untested.
> The tests can instead verify the actual responsibilities by calling public methods and making assertions about the returned values.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)