Using WebMock to stub an Oauth 2 Provider. The issue is that I want to use Rack Test.
Rack Test only runs against an instance of the app, and does not know about external HTTP hosts like the Oauth 2 Provider.
WebMock.stub_request(:get, "https://test.oauth-provider.com/oauth/authorize") won't work because the request is sent to the app as /oauth/authorize.
Is there a way for WebMock to respond to local requests? For example:
WebMock.stub_request(:get, "/oauth/authorize")
It seems to me, you're a little bit confused about what you're testing, and must draw the clear border, where your system is (so-called SuT, system under test) and where are the external parties.
It is very important since:
SuT is what you're going to interact with during your tests (i.e. your Rack application);
external parties are to be mocked (i.e. external web services, and... which may be surprising, other libraries, like OAuth, SQL drivers etc.)
That means that if you're trying to use WebMock for any part of your application (which it looks like what you're doing due to the question about mocking a relative URL), you're clearly doing something wrong.
Closer to your task, if I were you, I would:
Pick a good, well-tested OAuth library and drop it into the application.
When it comes to testing, just use my own simple stub objects instead of the real OAuth implementation classes. This will shift the focus on testing the behavior my service implements. Verifying OAuth library is really a double work, since it's already covered by its authors.
Hope this helps!
Related
My app has a React front-end and ASP.NET core Web API back-end. I've built some unit tests (i.e. which stub out fetch()) with react-testing-library.
Now I want to do an integration test calling the real back-end API over HTTP. There are lots of standalone API testing tools I could do this, but then I'm still not testing the interface between the React components and the server.
Is there any reason I shouldn't simply write jest tests that don't stub out fetch(), and achieve a real end-to-end test? this seems quite obvious to me but I haven't seen any articles discussing it.
FWIW after getting the first few tests going it seems to be a pretty successful approach. I have been able to "almost" remote-control the UI (by which I mean it's not actually running in a browser, but it is using my React components) without having to learn or set up selenium.
The biggest headache was JSDOM's implementation of fetch (which in their defence probably wasn't meant to do this kind of thing). I ran into lots of problems with cookies and CORS so I used node-fetch instead and this gave me much more control over the HTTP requests I was generating.
I maintain a web API written in Ruby. It connects to many third party web services. When writing tests, I stub any function that would need to connect to the network and return bottled data instead.
It has happened to me before that I forget this stubbing step, and my integration tests end up actually connecting to a third party service.
With that in mind, I would like to prevent Ruby from being able to open network connections. When attempted, I would like it to raise an exception instead, pointing out what function I forgot to stub.
Is this possible? What central Ruby function would I need to override to achieve this with minimal other side effects?
What about WebMock? Did you try it? https://github.com/bblimke/webmock
This line should help:
WebMock.disable_net_connect!(allow_localhost: true)
Manual stubbing is, as you've just said, unreliable.
A better solution might be to wrap your code that calls external services behind a facade, and use dependency injection to pass the web handling service into the facade on creation. Your Test Suite then just needs to do the same with a stub service. You'd only need to do this once, and any test which was then testing external code would use the stubbed service.
Check out VCR.
First, take a look at its documentation and see if it's what you need, which I suppose it is. We've been using it at my company for a few years to record one HTTP test for a spec and replay the results for subsequent tests.
We've found it to be invaluable when dealing with external APIs.
I am using rspec in my test and i would like to protect my API key it when i publish my gem on github.
What are the best practices to do that? should i use VCR and then remove my key from the git log?
Broadly speaking, here are three approaches I have used in the past in similar situations. Which you choose will depend on the details your particular situation.
Test user supplies API key
If your test suite requires, or at least prefers, actual API calls with an actual API key, you can have the caller of the tests supply the credentials when running the tests.
Two most common ways of doing this are:
File in project with well-known name which is not checked into version control. Include an example with fake credentials, which is checked into version control, along with instructions for users to supply their real credentials into the real file before calling test suite.
Read from environment variables. Include instructions for users to set appropriate environment variables before calling test suite.
Otherwise,
Mock out the API
This can be the VCR approach you described. This could also be patching the API call to return some fake results.
Test your domain-specific code separate from the API interaction
Assume the API and the API client behave how you expect. Then, factor out the parts of your code which construct the API input and process the API output. Test properties of your input generated. Test behavior of output processor with known or fake output.
Finally, a warning:
If you have ever committed your API key to version control, it will visible in the history. If you have ever pushed to a public hosting service, it will have been exposed to the Internet, most notably, it will have been exposed to specialized bots which scrape newly-pushed commits for sensitive credentials. If this is you, change your credentials now!
I can't find the original blog post at the moment, but there was at least one report of someone accidentally pushing their AWS credentials to GitHub. They subsequently woke up to a several thousand dollar bill.
I have an android app which communicates with server through REST calls. OAuth is used for authentication. Everything plays well, with signpost library and AsyncTasks.
Since AsyncTask has many flaws (memory leaks etc.), I was trying to implement REST calls with
RoboSpice library. RoboSpice is very cool. The only problem (and also a showstopper for me) is
that I can not figure out how does OAuth fit in with RoboSpice.
btw, I'm using robospice with spring-android.
I am one of the maintainers of RS. Personally, I never used OAuth with Spring Android. I only use the REST part os Spring Android.
So, I don't have any idea of what could be missing. Would you mind to give more details on what's blocking you ?
Normally, it should be pretty easy to inject anything into a RS service.
Are there any best practices in writing unit tests when 90% of the time I'm building the Oauth connecting class, I need to actually be logging into the remote service?
I am building a rubygem that logs in to Twitter/Google/MySpace, etc., and the hardest part is making sure I have the settings right for that particular provider, and I would like to write tests for that.
Is there a recommended way to do that? If I did mocks or stubs, I'd still have to spend that 90% of the time figuring out how to use the service, and would end up writing tests after the fact instead of before...
On a related note, if I created test API keys for each Oauth provider, and I just used it for the gem for testing purposes, is there any issue in leaving the api key and secret in plain view in the tests? So other people could test it out more realistically too.
nothing wrong with hitting live services in your integration tests.
you should stub out the oauth part completely in your unit tests though
If you're planning on open sourcing the code you're writing, leaving API keys in the code might not be a good idea as you might hit API usage limits or rate limiting when the gem becomes popular and people run the tests frequently which will lead to unexpected test failures.