Hi @erawhctim,

We are giving this some consideration and we have added an item to the backlog to add some additional in depth information to our docs around our recommended ways on how to mock BugSnag.

Appreciate it may be a little tedious in places but for now our recommended suggestion would be to use static mocks and utility methods, like you suggested.

We will post here with updates.

Ok, that makes sense. Thanks for the update!

Has any internal discussion moved forward on this? Or is mocking still the preferred method of replacing BugSnag SDK functionality in tests?

Hi @erawhctim

Thanks for bumping this. We still don't have anything scheduled, but it would good to get a clear idea of what will help.

We'd ideally like to keep any "test specific" logic out of bugsnag-android-core if possible, I'd like to know if a way to side-channel this functionality would cover what you need. Something along the lines of a new bugsnag-android-testing module that would allow:

BugsnagTesting.setGlobalClient(myMockedClient)
BugsnagTesting.clearGlobalClient()

Would that be enough? Or would you need some other functionality?

That would be great! I agree that offering a separate testing client makes the most sense 💯

Ideal use case (IMO):

• Client would be an interface that we could implement ourselves, avoiding the need to use mocking frameworks.
• The testing artifact would allow me to clear the Client and set it to null (to help simulate the "you must call Bugsnag.start" error scenarios)

Right now there isn't any other functionality we would need; all the Bugsnag.something calls end up routed through to the underlying Client right?

Unfortunately we're not likely to make Client an interface for the foreseeable future, as that would be a major breaking change in the API (as nice as it might be from an extensibility perspective).

Other than Bugsnag.start, Bugsnag.isStarted, and Bugsnag.getClient all methods on Bugsnag are just proxies to the global Client. It's entirely possible to skip using the Bugsnag class entirely, and use a Client instance instead (its constructors follow the same pattern as Bugsnag.start)

got it, ok. Yeah if we still need to rely on Mocking tools to control a test-specific instance of Client, I'm not sure if offering a testing artifact would change anything over what we do today (unfortunately).