Improve the testing experience when using this library

[devigned]

Expected Behavior

It should be easy to mock dependencies on this library.

Actual Behavior

It is difficult to mock behaviors in this library due to a mix of public / private struct fields and limited use of interfaces in the public interface.

The problem is that this is likely to be a breaking change to the interface and thus would probably need to land in v2.0. This is issue is to track this and to ensure in the next major version testing / mocking is handled better.

#77 spurred this discussion and contains an example of problem.

Environment

• Version of Library: v1.0

[christothes]

@devigned I'd like to take a crack at this one to get more familiar with golang and this repo. Is there anything I should be aware of before I dig in?

[devigned]

Well, I am not an active maintainer of this repo any longer. Those duties now fall on @jhendrixMSFT et al, so I'd defer to their team on any guidance / feedback.

This is super Golang'ish background, so please ignore if you are more advanced in Go. Just wanted to provide a bit of a foundation if it isn't there already. I think the biggest thing to grok with Golang vs say C# or Java wrt testing is that an interface in Golang can be defined by anyone and used for duck typing on a type defined in another package where as in Java and C#, a type must implement an interface explicitly at time of type definition. Therefore, defining testing interfaces within a package in Golang isn't really needed. What is needed, is easy access to the structures, fields and methods defined on types.

If you were to write a simple application using this library, then try to mock out the library like in #77, I think you will quickly see where this becomes a problem with this library.

Perhaps, there's too much encapsulation of types / fields or maybe too much coupling. Either way, I think when you try to mock it, it will become clear where the runtime blows up and where you find yourself feeling less productive having to rewrite a lot of structure just to be able to test.

The changes may cause breaking changes in the API. This is something to try to avoid, if possible. Also, it's something you'd want to call out to @jhendrixMSFT and team.

Happy to help. Please don't hesitate to ping me if I can be of service. Cheers!