-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Wrap ably-java
in a set of interfaces and add example unit test for DefaultAbly
#868
Conversation
97a2e06
to
66d13a8
Compare
66d13a8
to
3e75bad
Compare
ably-java
in a set of interfaces and add example unit test for DefaultAbly
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great job 💪 I've left a few comments and suggestions 😉
Also the test could use some refactoring, however, I know that this is just an example test so wouldn't want to block this PR on the test refactoring 😉
common/src/main/java/com/ably/tracking/common/DefaultAblySDK.kt
Outdated
Show resolved
Hide resolved
The DefaultAbly class already has quite a bit of logic (e.g. retries) and I intend to add further logic to it. It would be good to be able to unit test this class. It sounds like we haven’t done this so far because we didn’t want to try and mock the AblyRealtime class. But I think we need to be able to unit test DefaultAbly (which I’ve created issue #869 for), so I’m putting the ably-java library behind a set of AblySdk* interfaces. This will allow us to provide mock implementations of the Ably client library when testing DefaultAbly. (I’ve taken this approach from the asset-tracking-swift codebase.) One thing worth noticing is the new use of the !! operator when extracting the `reason` from a connection that’s in a failed state. This looks like it’s introducing a new unsafe behaviour, but it’s actually just making explicit a previous assumption, namely that when a connection is in a failed state its `reason` will be non-null. The previous version of the code - in which the connection’s `reason` was of platform type ErrorInfo! – would equally have thrown a NullPointerException if this assumption were violated.
This is just to check that the interfaces created in 934ec93 are fit for purpose.
3e75bad
to
9b76214
Compare
Don't worry, you'll have plenty of opportunity to critique my tests when I write some for #862 😁 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 👍
This introduces a set of interfaces,
AblySDK*
, which represent all of the functionality ofably-java
used by this SDK.This allows us to mock out
ably-java
in unit tests and hence to write unit tests forDefaultAbly
, which is currently untested (I've created #869 for writing tests for all the existing behaviour of that class).I’ve also added one example unit test for
DefaultAbly
, just to confirm the new interfaces are fit for purpose.See commit messages for more details.