Closed andymac4182 closed 5 years ago
At the moment, ISeqConnection
specifies the minimum contract between the connection and some of the other types that use it, e.g.:
https://github.com/datalust/seq-api/blob/dev/src/Seq.Api/Api/ResourceGroups/ApiResourceGroup.cs#L15
The goal of using a narrower interface was just to keep coupling down within the library.
If a public ISeqConnection
would be useful, we could rename the existing type and create a full-fledged public ISeqConnection
with all of the members 👍
Should I possibly be using a different interface? I was just looking for the ability to mock out the calls to Seq in Unit Tests.
There isn't currently an equivalent public interface anywhere - though thinking about this some more, a proper testable abstraction would also require some way of mocking out the various resource group classes that are exposed as ApiKeys
, Users
, and so-on.
Depending on how broadly you're using the interface, would wrapping the Seq API with an app-specific abstraction be a bit simpler to pull off?
I can build a layer inside my application for testing. I am only using a few methods for accessing Signals and API Keys at the moment.
Sounds like you were able to move forward on the alternate approach; closing, but let us know if we should revisit this.
I am working on an application that deploys the config for an application to Seq. Is there a reason that
ISeqConnection
is internal and doesn't include all the public methods? https://github.com/datalust/seq-api/blob/dev/src/Seq.Api/Api/ResourceGroups/ISeqConnection.cs