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.
Related
I have FastAPI project which does the following:
Register users(unauthenticated)
CRUD operations on user resources(authenticated)
What I want to do:
Develop an automated testing framework to unit test all the APIs
Run that on a devops platform like jenkins regularly
Run it locally before deployment
Some specific doubts I have:
For testing, should I use the OpenAPI generated client sdk or the FastAPI client or use the python requests module?
Authentication should happen only once and reuse the JWT token or fresh authentication for each API test ?
Should I use the same pydantic modules for dev and testing or re-write them to ensure that no issues were introduced in case of updated models ?
How to do proper unit testing when one API requires result from multiple other APIs?
Use the built-in TestClient
Use a fixture and let pytest sort it out for you; if it's too slow to reauthenticate each time, change the scope of the fixture to a larger scope (i.e. class, module, session, etc.). You can also use FastAPI's dependency_overrides to let your tests run with static authentication configured (so that you can skip actually authenticating in most of your tests).
You should test what you use in your application. Nothing specific written for your tests, except if necessary to make your application testable in a better way.
The only "proper" thing is that your API has been tested to work as you expect it to work. Do multiple API calls if necessary, but move them into fixtures to get composable sets of dependencies for tests (i.e. the result of the fixture can be cached and re-used for all tests in a test class if necessary). If you have tests that depend on a customer being created, create a fixture that creates a customer and use that fixture in the tests where a created customer is necessary.
Let's say I have a frontend application written in Angular and a backend application written in Django and Django Rest Framework. I created unit tests for backend application (with pytest) and I'm about to create some functional tests for the frontend application. The thing is that the frontend app needs access to the backend app in order to work correctly. I can write some mocks to handle that, but I am not sure if this is the best way to do that.
My question is, what is the best way to handle that? Should I use a single git repo for both applications or maybe a better way is to use two repositories, but then how to handle the tests for frontend application?
I was also thinking about using selenium with pytest, but then I would have to use a single repository. I am a little bit confused and would really use some good advice. Thanks!
Unit tests as the name suggests is testing separate units of the code in isolation. Meaning that it does not have to depend on any other part, else, you wouldn't know if the test is failing for that particular unit or the units it depends on.
As a result, all tests should mock the request to the backend and return valid responses (or invalid, if you're testing for error handling). The same applies to any other external service that the unit depends on.
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).
I am still trying to totally understand BDD and I am facing some doubts.
From my little experience, I have been using it to automate user acceptance test and I would like to know if it's possible to use it to test a web API, without UI.
In the past I've used BDD using the given-when-then jargon and mapping the steps to UI interactions. I've done this with Specflow in ASP.NET or cucumber/capybara in ruby on rails.
So for example we could have scenarios like this:
Given I am in the home page
When I click login button
Then I should see the login page
The current project I am working at is different. We are implementing an API based in web service which would be consumed by different type of clients. Like an iphone app, android app and an asp based web client. So our main focus is based in the back-end and just that.
In this case, the tests can't be faced from the UI point of view. So our end-to-end tests are based in our service endpoints. We pass some input arguments to a service calls and check the outputs.
Can we do this using BDD? Is this right?
or maybe it would be better to use a different thing like FitNesse?
Hmm.. is using FitNesse doing BDD?
I think you can do what your writing about in BDD. I'm not sure if those 2 links about testing of webservices with SpecFlow will help you but take a look on them if you haven't seen it yet.
http://codedetective.blogspot.co.uk/2012/10/testing-webservices-with-specflow.html
http://www.creamdog.se/blog/2011/02/24/webservices-automated-tests-using-specflow-and-babelfish/
Have a look at Karate, web service testing framework by Intuit. It's recently being open sourced. It has the capability of handling API dealing with HTML, JSON, XML, GraphQL queries and is built on top on cucumber.
Simple intro here : https://medium.com/blueprint-by-intuit/karate-web-services-testing-made-simple-366e8eb5adc0#.qnpy5gagt
I know this question was asked million times but I'm gonna ask it again. I've been researching how to test web services for a while and I can't believe that there's pretty much one tool out there: SOAP UI. The other option that you have is creating web services stubs and writing unit tests per each ws stub.
I can't believe that Microsoft didn't come up with a solid solution for web services testing. So I guess my question: is SOAP UI the only tool for testing multiple web services?
P.S.
I'm also looking for something to integrate with TFS (I know SOAP UI can be integrated with msbuild)
Thanks
There are always options! Here an old article that could help out includes soapUI, Push to test and WebInject.
Looking to shell out dough? You could always use HP Service Test
Which do I use? soapUI of course :) Frankly, it's the most commonly used for a reason.
My alternative to soapUI is HP Service Test.
If I have to build a testing team with testers that are not exposed to web services and SOA in general, then the learning curve and team ramp time associated with HP Service Test is short essentially because of the Canvas based visual drag and drop designer that Service Test boasts.
Perhaps, everything you could do with HP Service Test 11.20 is possible with SOAP UI 4. They both do have striking inherent features that is kind of mutually exclusive between these two.
If your organization already uses HP's Quality Center, QTP and Load Runner, then for easy effortless mangement of all test cases in your app's boundary it is preferred to have HP Service Test because it integrates with all the aforementioned products.
With Service Test, I personally like the Canvas designer in HP Service Test and the ability to call .Net assemblies inside of Service Test is just a boon as I am a .Net developer. And the ToolBox has a list of controls that every tester/dveloper needs. And it is just efforless to built a hi-fi test case with Service Test. It is worth the money.
With soapUI, I like the HTTP Recording (works much like Fiddler) and the Security check options (to name a few, XSLT injection, XSS checks).
soapUI is omnipresent.
TFS integration, I am not there yet.