search

SpectoLabs / hoverpy

Python library for Hoverfly (now obsolete)
Apache License 2.0
79 stars 9 forks source link

Replace external calls on the tests #13

Open alvarocavalcanti opened 6 years ago

alvarocavalcanti commented 6 years ago

Currently, the test cases send requests to an external URL, which is a brittle dependency. Hoverpy should not rely on this approach. Instead, I suggest the use of a simple, internal web service, to be started on the setUp and closed on the tearDown.

We could use a lib as https://cherrypy.org to achieve this.

shyal commented 6 years ago

If you were to spawn a web service for this, then you may as well go with tornado. I'm no longer involved with this project, although I can merge changes in. I won't be doing a release though. Maybe John from SpectoLabs can chip in.

JohnFDavenport commented 6 years ago

It is a little ironic to say the least that the tests for a tool that is intended to remove dependencies depend on an external (brittle) dependency! I'm sure was a bit of technical debt added to get things done quickly. We (SpectoLabs) are concentrating on Hoverfly, Hoverfly Java and Hoverfly Cloud at the moment. We don't have any Python expertise available at the moment to progress this but would welcome contributions. If it's useful to the Python community get in touch and I'd be happy to discuss a new arrangement for its maintenance.

shyal commented 6 years ago

The irony is indeed palpable. 🥇It was a design decision however, as I was reluctant to bring in another dependency. In the interim, I'd requested for HoverFly to provide those endpoints, so I could test against that data directly. We never get around to it though, and the external dependencies remained. They are in the examples too.. I can always get those endpoints back up. This needs looking into. Would also like to hear about how HoverPy is being used.

shyal commented 6 years ago

https://github.com/SpectoLabs/hoverfly/issues/413

JohnFDavenport commented 6 years ago

Hoverfly certainly has a webserver mode so that's probably the easiest solution with no external dependencies.

alvarocavalcanti commented 6 years ago

That seems to be a good approach, but I need to call it out that pointing to a hoverfly URL it's still an external dependency that would require both internet connection and the hoverfly server to be up and running.

If you guys are talking about Hoverfly as a service in the host machine, that's still a dependency external to the lib itself, but that's maybe ok since one should have it running in order to use hoverpy in the first place.

In another hand, if we take the python-lib approach, this new lib can be added as a development-only dependency and the tests would be self-sufficient. I can help with this approach, but I cannot provide an estimation right now.

JohnFDavenport commented 6 years ago

It's in the host machine for unit tests at least. The philosophy of Hoverfly Go binary that it runs anywhere and Hoverpy is a wrapper that hides the over-the-wire element. In unit testing the Go binary will be local. In other tests, integration, end-to-end and performance testing Hoverfly will typically be remote. The idea is you would use a simulation in unit testing and then re-use a number of simulations in end-to-end testing with multiple Hoverfly instances.

The intent of Hoverpy is that it must implement unit tests with a local Go binary.

alvarocavalcanti commented 6 years ago

If that's the case, then using Hoverfly itself as the web server is a no-brainer. 😁