I write a lot of apps that end up integrating with Google Drive for one reason or another. It's such a useful cloud based storage utility that it's got integrations all over the place.
So many of my integration tests are needing to call the actual Google API. Such a waste.
You can use Mockito to mock it, but that's a ton of work. And it's only for unit testing that has stubbed out mocks.
Has anyone made a mock HTTP web service that can mock the Google drive api?
I was hoping to find someone who created a Docker container that fires up a mock Google drive api that you can point the Google-drive-sdk to and have it work from a linux filesystem backend.
S3 has this. Example: https://hub.docker.com/r/lphoward/fake-s3/
I'm pretty sure no such docker container exists. Is there there anything in the makes at Google? Thanks for your time!
Here's what I have found:
For JAVA:
Please try checking HTTP Unit Testing. As mentioned in the documentation:
When writing unit tests using this HTTP framework, don't make requests to a real server. Instead, mock the HTTP transport and inject fake HTTP requests and responses. The pluggable HTTP transport layer of the Google HTTP Client Library for Java makes this flexible and simple to do.
Also, some useful testing utilities are included in the com.google.api.client.testing.http package (#Beta).
For Android:
If you're using Android Studio, the location of your test code depends on the type of test you are writing. Android Studio provides source code directories (source sets).
Local unit tests
Located at module-name/src/test/java/.
These are tests that run on your machine's local Java Virtual Machine (JVM). Use these tests to minimize execution time when your tests have no Android framework dependencies or when you can mock the Android framework dependencies.
At runtime, these tests are executed against a modified version of android.jar where all final modifiers have been stripped off. This lets you use popular mocking libraries, like Mockito.
You may want check this SO post and see if it helps.
For Python:
You may try Mocks.
The use of Mock objects is a standard testing methodology for Python and other object-oriented languages. This library defines Mock classes that simulate responses to API calls. You can use them to test how your code handles basic interactions with Google APIs.
You can use the HttpMock class which simulates the response to a single HTTP request.
Hope that helps!
For python, if you are brave, you could use vcrpy as gcsfs does. It records all requests and responses over HTTP into YAML files, which you can then test against, with complex matching (so that, for instance, etags and timestamps don't matter) and replacement rules (so that secure data isn't leaked into version control).
Related
I'd like to write unit tests for some of my network logic in an Electron app, and need to mock out the network endpoints.
In the past, I've used nock for mocking out HTTP requests in Node. However, my Electron code uses the electron.net module for requests (instead of Node's http module), and Nock doesn't intercept these requests.
What is the best way to mock Electron network requests?
You can easily mock your API with Postman:
https://learning.postman.com/docs/postman/mock-servers/setting-up-mock/
I highly recommend this simple, platform independent, and open source tool for local testing:
https://www.electronjs.org/apps/local-mock-server
This is much simpler than paid-for options like postman, but I'm guessing the author would be very amenable to enhancements if you propose a PR here:
https://github.com/jayakumarreddy/Local-Mock-Server/
The configuration simply lives in your home directory (~/.config/local-mock-server/mocks_folder/ on Linux), so what I do is simply check these mocks into my git repo and symlink them there, that way everything I do is repeatable for someone else. Just double click the AppImage (on Linux) to enable the mock and leave it minimized for as long as needed. Done.
My project has gotten into web services lately, but our QA team has a request to be able to set up a clone client and clone web service so that they can issue a request from the clone client to the real web service and from the real client to the clone service to test the real pieces individually.
The clone client to real web service part is easy, I just wrap the generated client in a main() app that picks up data to send that the test team specifies. But the service part is confusing to me. How can I make a dummy service that just echoes out its requests to a log without affecting the real service? I want the real client to use the same generated client code, just point the soft-coded URL to the URL of the dummy.
If I define a new web service with identical names and signatures to the real service, can the real client hit the dummy with just a URL change? Or is it more complicated? Am I barking up the wrong tree?
Re: Making a dummy service
This would actually be called making a "mock" service or a web service "stub". You don't even technically have to code it - you can use tools. For example, SoapUI has the ability to import a WSDL and create a mock service. The have some other discussion of mock services as well - they can be used both to test the client application (or to simply develop it before the back-end resources are ready or available). To use a WSDL-based service stub you would simply change the endpoint of your client-under-test to the stub instance. SoapUI will show you (and let you configure) the stub's endpoint URL.
The trendy term for service mocking and stubbing is "service virtualization" (not to be confused with server virtualization as in virtual machines). Searches using this terminology will find you even more powerful (and expensive) tooling.
Re: Just a URL Change
Yep, for the most part. So long as the XML namespaces are the same and the WSDL is the same (minus endpoint URL) you should be fine. Since the WSDL acts as an interface contract, the stub MUST accept those same inputs and produce those same outputs. How it does so, of course, is up to you.
PS - free extra advice - Don't code a dummy client. Use tools (I'll use SoapUI again as an example free tool) to make your web service testing more robust and repeatable. You can create test suites with sample SOAP requests, add assertions on how the service should behave, and best of all - your investment in time of creating a test project can be shared across team members, cutting down time to test setup and making sure testing is thorough and repeatable. If you code a client, every tester/user of the test client will have their own way of testing, response inspection will probably be manual, and you'll notice when your best QA tester goes on vacation because regressions slip into the web service product. Repeatable testing can nix this, and tool based automated functional testing is the bees knees. You're already on the right path by testing the pieces individually.
My web app is a Google OpenID consumer (with Attribute Exchange and OAuth Extension) and I need to write some unit test for it [edit: to test the unit that is responsible to interact with google].
The problem is that default OpenID login procedure needs user interaction (entering user/pass) which is not possible in unit test.
Do you have any idea how can I solve this problem and unit test my OpenID consumer app?
(I prefer not to run my own OpenID provider.)
You need to use a remote controlled browser for this. Selenium was made for this use case.
(indeed they are called functional tests then).
Search on Google for the best way to integrate selenium tests into your web framework.
If I understand you want to test your all application and not just "unit test" it.
The actual test framework depends on the technology your application is using. For example there are many UI and web automation tools that can do what you want.
You should also unit test your core functionality or at least write several integration tests that work against an actual Openid provider but instead of running the entire application just test the functionality of the class (if you're using language that has classes) to make sure it can get the b.
I would also write a couple of unit tests that call a fake provider to test how your code behaves in case of error, connection problems and plain vanilla responses.
I'm at the point where I need to write unit tests for a REST API written using CakePHP 1.3. The API supports GET, POST and PUT requests for querying and manipulating data.
Is there any established way to test the correct input/output of an API simulating an HTTP request, using fixtures? I do not want to run actual POST/PUT requests against the live (dev) database. How can I best mock out the system to use temporary models, yet test the rest of the stack as-is?
Testing GET requests is easy enough with controller tests. However, for data manipulation the API uses HTTP headers quite extensively and also parses raw XML and JSON POST/PUT data. The controller unit test methods only mock POST data by setting $this->data in the controller, which does not allow me to properly test the API.
You should either create Mocks or use Isolation Framework in order to simulate API environment. Unit tests should not depend on resources like internet connections, network, endpoints etc.
If you intend to test real API calls you should create integration test project and use it for this purpose. But be aware integration tests are mostly not repeatable and would give you different results on each run.
I'd recommend starting with a little research. These articles should help:
Unit Testing CakePHP Shells
Testing CakePHP controllers - Mock Objects edition
Testing Models with CakePHP 1.2 test suite
Looks like you might be able to test the raw XML PUT and POST data without too much trouble. The CakePHP REST documentation says this:
If a POST or PUT request has an XML content-type, then the input is taken and passed to an instance of Cake's Xml object, which is assigned to the $data property of the controller. Because of this feature, handling XML and POST data in parallel is seamless: no changes are required to the controller or model code. Everything you need should end up in $this->data.
Try stepping through your controller code in debug mode to see what actually comes in through $this->data during an XML request.
As for avoiding the live database, would a SQLite in-memory database be any easier?
I am a novice in web services. I am totally new to testing web services.
A new project demands that I test the web services, and the customer is in favor of any open source tool.
What is the approach to testing web services?
Also Please suggest a tool(with minimal scripting) to test web services?
Check out SoapUI - one of the best web service test tools - plus it's free!!
They also have a "Pro" version which costs - you can do more stuff, like load testing etc., but the free version is quite good enough for most of your testing, I'd say!
Given a WSDL (online or stored as file), it'll create stubs for each method, which you can then use to create requests (as XML), fill in the blanks (the parameter values), and then you can send off your request to the web service and see what comes back as a response.
SoapUI also allows you to write scripted tests than can be run over and over again.
Excellent tool - can't praise it enough!
Marc
Additionally you could use Firefox Poster in order to test your web service by passing XML-packets manually.
Check it here:
FF Poster
SoapUI is a great tool to test SOAP webservices. It allows you to test a SOAP client or a SOAP server.
Another very useful tool is Fiddler. Fiddler isn't necessarily aimed at testing webservices (it's a HTTP debugger), but since SOAP webservices run over HTTP, you can use it to testing. Another very important advantage of using Fiddler is the fact that you can test REST webservices also.
You might want to consider robot framework. It is a generic, keyword-driven testing framework. There are libraries for testing REST and SOAP based web services. It can also be used to test web pages (via a selenium library), databases, and a whole lot more.
robotframework has a ton of built-in keywords, and there are additional libraries that do much more. You are also able to develop your own keywords in python, java, .NET languages, or any other language.