Skip to content
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

Improve the testing experience when using this library #82

Open
devigned opened this issue Dec 10, 2018 · 2 comments · May be fixed by #164
Open

Improve the testing experience when using this library #82

devigned opened this issue Dec 10, 2018 · 2 comments · May be fixed by #164
Labels
enhancement New feature or request

Comments

@devigned
Copy link
Member

devigned commented Dec 10, 2018

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
@devigned devigned added the enhancement New feature or request label Dec 10, 2018
@devigned devigned added this to the v2.0 milestone Dec 10, 2018
@devigned devigned removed this from the v2.0 milestone May 3, 2019
@christothes
Copy link
Member

@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
Copy link
Member Author

devigned commented Jan 13, 2020

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!

@christothes christothes linked a pull request Feb 17, 2020 that will close this issue
2 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants