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

Tests for more core functionality - mocking request calls to bridge #19

Open
finnkauski opened this issue Aug 23, 2020 · 3 comments
Open
Labels
enhancement New feature or request good first issue Good for newcomers help wanted Extra attention is needed tests

Comments

@finnkauski
Copy link
Owner

Is your feature request related to a problem? Please describe.
This basically relates to the fact that the bridge as of now is not fully tested because we need to mock request calls to a bridge with our own bridge somehow in order to be able to test.

Describe the solution you'd like
This could be implemented in the form of a bridge tester struct that spins up its own thread and listens to requests on a given port and responds with premade json files.

@finnkauski finnkauski added enhancement New feature or request help wanted Extra attention is needed good first issue Good for newcomers tests labels Aug 23, 2020
@ssnover
Copy link
Contributor

ssnover commented Aug 23, 2020

Possible alternative would be to use the a simulator project for the Hue Bridge that already exists (that's more or less what you're suggesting with the premade JSON). The main problem is finding one that's up-to-date with the API: this fork of one I've used was last updated 2 years ago.

Alternatively, (this is how I'd do it in C++, but I don't know if Rust has some details that make this different) you could wrap reqwest::Client in an wrapper that implements a trait. Then you could dependency inject a mock during construction of the Bridge. Either way is kind of a pain admittedly, it'd be great if Philips published their own simulators...

@finnkauski
Copy link
Owner Author

finnkauski commented Aug 26, 2020

The later suggestion about a trait sounds like a good way to mock stuff. I just wonder what burden it adds to the maintenance process. I think easiest would be to write a simple web server (simulator) that is spun up in a seperate thread during testing as a fixture that is able to handle the requests sent by responding with premade json. I think writing it for the few use cases we have isn't that much work using something like actix or whatever else. And in the case of expanding the API coverage more things could get added to it to the point where eventually it could become a fully fledged simulator as you say. But for the mean time a simple web server will probably do.

@finnkauski
Copy link
Owner Author

finnkauski commented Aug 26, 2020

Note to future-self: Rust has a way of defining a custom test runner as well. So I think we could definitely figure something out with a bit of head scratching.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers help wanted Extra attention is needed tests
Projects
None yet
Development

No branches or pull requests

2 participants