Skip to content

Don't use global SDK state for controlling test behaviour #1601

Description

@lawrence-forooghian

We have a lot of places where we’re using global state to change the SDK’s behaviour in test cases. Global state means that the execution of one test case can influence that of another, leading to issues such as #1241, which prevent us from making changes that we might like to in the future, such as running the tests in parallel (because one test may have some hidden accidental dependency on another test having run before it).

In #1603 I gave an example of how we might go about removing this global state, by removing the setter for +[ARTDefault realtimeRequestTimeout] and instead injecting it into the SDK via an ARTTestClientOptions property. We should do the same for the rest of the global mutable state in the SDK. That means removing the following setters:

  • +[ARTDefault setConnectionStateTtl:]
  • +[ARTDefault setMaxMessageSize:]
  • +[ARTWebSocketTransport setWebSocketClass:]
  • +[ARTClientOptions setDefaultEnvironment:]
  • +[ARTHttp setURLSessionClass:]
  • mutable ARTFallback_shuffleArray variable — done in Make ARTFallback_shuffleArray constant #1672
  • -[ARTRestInternal resetDeviceSingleton] (WIP in Mock device fetcher #1681)
  • use of ARTLocalDeviceStorage, which writes to the keychain and user defaults
  • use of testSuite_injectIntoClassMethod

This issue only relates to the global state in the SDK. The test suite itself has global state, too, which we'll need to address separately (#1604).

┆Issue is synchronized with this Jira Task by Unito

Metadata

Metadata

Assignees

No one assigned

    Labels

    code-qualityAffects the developer experience when working in our codebase.testingIncludes all kinds of automated tests, the way that we run them and the infrastructure around them.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions