The mocking bird

[gildub]

Can we please remove mock?

There are several reasons to remove the Mock class or at least move it away into unit tests. Also, I believe I'm not the only one thinking in such way about the mock, so it seems to be the time to discus it.

Looking back, some time ago, I was thinking having unit testing capability close to the source was a good idea, meanwhile experience proved otherwise.

The mock class is more a burden than of any help. The main issue, as far as I can see, is because the Service class is in essence only a conduit to cloud APIs. So there no real need to extensively mock them, by doing so, it makes it wrong and is waste of time to write tests that are 'unrealistic' tests. To make that crystal clear, I've used my own service replacing the default ones, and guess what, not matter what I do, the tests are always GREEN.

Fundamentally, once the service pattern is tested for once and for good, the API service which consist of sending a path and a hash(.to_json) and getting a response, leaves the rest to integration tests like VCR. The latter part actually tests an API works.

Also the unit test code shouldn't appear in production. Normally when packaging the gem, the test folder(s) is left aside. Well that's impossible to do because the Mock class is embedded into the Service subclasses.

So, can we, please?

[plribeiro3000]

TL;DR

@gildub is proposing we drop the Mock feature entirely or push it to another gem because it is more of a burden to maintain than it helps (in his opinion).

I'm not sure how such change will affect the other providers so i would like to get an idea of it if possible thus why i summoned more people here.

[geemus]

@gildub thanks for continuing to talk through this with us.

To clarify, you say that it slows down refactoring, while not impacting new requests. Is this because when we change existing stuff we have to update/maintain the mocks at the same time? Perhaps we should consider having major updates use similar behavior to new requests (ie MockNotImplemented), with the expectation that others can come back and add that if/when they want it. My expectation has always been that people will mostly add stuff as they need it. Perhaps this could alleviate some of your concern, without needing to make more drastic changes? The downside here is more around communication and expectations (ie users updating to a new version probably don't expect mocks to stop working). If this is a direction we want to go, however, we should have more discussion. Perhaps an in between would be that the mock could warn that things needed updates instead of failing outright?

As for where in the structure of the code it lives, I'm not sure it matters to me all that much. Having it alongside the Real stuff was helpful to me, as it kept me honest about maintaining the mocks alongside the Real changes. But I understand that isn't as valuable to everyone (and that is probably ok).

The most important shared part is our shared end user interface. There are already differences among individual providers and how they approach things in many ways, which is probably fine. The downside, of course, is that it may make it harder for cross-contribution from other maintainers if the code structure changes in a particular provider, but I don't really see that happening a ton in practice anyway. That said, moving it all seems like a good deal of work that wouldn't necessarily have a lot of impact at first. If we are going to do other refactoring work, perhaps we should wait to see the outcome of that, lest we have to move things twice?

I'm certainly open to discussing ideas around better ways to decouple and clean up this code (which I largely wrote many years ago and would likely do differently now), but as suggested, it is now more complicated/costly to change due to usage across the suite of services. I'm not opposed to changes, but we should take care to only impose that if we are certain the outcome is worth the effort.

Hope that helps, again, happy to continue the discussion until we can reach some shared conclusion.

[gildub]

@plribeiro3000, I acknowledged several times already that I understand keeping the feature is important. Although I don't use it and I was initially keen to put it on the side. The idea has evolved to work on a re-factor to relocate it to it's own name space in order to provide more flexibility (I'm not talking about gem, that's another discussion if it makes sense later).

@geemus, as you said this was written long time ago, and beyond the Mock feature there is re-factoring that's due. Such work is going to be hard but beneficial. So are you willing to do it or not?

Thank you for your time and help.

[gildub]

I've reverted https://github.com/fog/fog-openstack/pull/223 with https://github.com/fog/fog-openstack/pull/376 since we effectively need proper work on the base for this to eventually happen.

[geemus]

@gildub thanks for your understanding. I'm definitely willing to discuss refactoring and support efforts around what we end up deciding, but it's harder for me to say I'd have a lot of time to do the implementation of such changes these days. I'd be happy to assist in others making changes toward better abstractions though.

[gildub]

@geemus, @Temikus and @plribeiro3000 ,

First off, thank you for your participation.

Looking forward for those plans.

[plribeiro3000]

@gildub I'm in to do the refactor. We have several providers without an active maintainer that does not have any Mock at all.

If we get a 👍 from at least one of the major providers i can do all the work in the smaller ones plus the deprecation on fog-core initially.

@gildub Thanks for your understanding here.

[gildub]

@plribeiro3000, no worries, at the end you're right, it has to be top-bottom. The approach sounds good.

[plribeiro3000]

@gildub I don't like the sound of top-bottom here. =)

I prefer to say that i depend on your contributions to keep fog-openstack going and that my main job is to help where i can and to make sure the whole structure don't fall apart.

In some cases this means i need to check with everyone involved before we start doing something and in some cases it means i need to coordinate with other maintainers of other providers.

This particular case is one of the later.

Now that we agreed on something i believe we can start working something out. Hope this helps you out at least a little bit. 😃

[plribeiro3000]

@gildub By the way, we do use slack to communicate among us (maintainers). Would you be kind to drop me an email (plribeiro3000@gmail.com) so i can invite you over?

Thanks!

[gildub]

@plribeiro3000, looking forward to it. Please use my email (gilles@redhat.com) although because of my time zone down under our overlap time is reduced.

[plribeiro3000]

Just invited you. =)

[stale[bot]]

This issue has been automatically marked stale due to inactivity. It will be closed if no further activity occurs. Thank you for your contributions.