My vuejs front-end makes API calls using Axios.
I'm making unit tests and integration tests with Jest. I use axios-mock-adapter to mock API, but I need to mock every endpoint.
To make it easier, I'd like to use json-server. On a development machine, there is no problem : I launch json-server, then I launch Jest tests.
My question is about Travis CI:
How do I launch json-server?
How can I be sure to have an available port
How/when do I stop json-server?
Related
I am trying to build a pact verification against consumer contract using python. Basically I am reading the consumer pact from the broker and trying to verify it. The provider real API is hosted on GCP.
I am really confused if I need to create a provider mock ( I thought we create it only on consumer side) to run the verification or I have to run it against the production API (hosted on GCP)?
In the case it is a provider mock on localhost, how should I built it?
Actually when it is running locally, I feel like I am going to hard code the actual response as in the user-app.py. Hence, when the production API change, I have to reflect that change manually on the user-app.py. I feel like I am missing something.
Here is the contract
to run the verification:
pact-verifier --provider-base-url=http://localhost:5001 --pact-url=tests/recommendations.recommendations-api-recommendations.basket.model.json --provider-states-setup-url=http://localhost:5001/_pact/provider_states
With Pact you only mock the provider on the consumer side, because you're unit testing the consumer code.
When you test the provider, Pact stands in for the consumer, so you absolutely do not mock the provider here (otherwise, what confidence would you get?)
You should:
Run the provider locally (ideally not to a deployed environment, the kind of testing we are avoiding and usually helping to replace with contract testing is end-to-end integrated tests)
Mock out any third party dependencies to increase reliability/determinism
See also this page on testing scope: https://docs.pact.io/getting_started/testing-scope
You may find these examples helpful.
My end-to-end tests are ran against a local docker environment of a micro service I'm testing, I want to mock out a request made via that docker environment from the end-to-end test but it just doesn't seem to let me.
const requestNock = nock('https://google.com').post('/foo').reply(200);
makeRequest('127.0.0.1/bar') // This path then calls https://google.com/bar
requestNock.isDone() // Returns false
Is something like this possible? If not is there any solution to mock out an external API's response made via a local docker environment?
This is not something Nock is designed to handle. It works by intercepting outbound HTTP requests inside a single Node process.
Without knowing more about what your docker does it's hard to say what your options are. If the service inside the Docker container has no logic and it's only purpose is to proxy requests during your tests, then I'd argue that it should be removed from the test and you can Nock out the requests inside the single process. I would call these integration tests.
Since you specified your tests are end-to-end, I have to assume the Docker service is more than a proxy. However, you usually don't want to nock any requests of end-to-end tests as it negates the advantages over integration tests.
I have a redux-saga that periodically yield call(fetch, url)
I'd like to have a cucumber feature that tests this app behaviour. Not the saga itself. I have such tests already.
I fail to understand how I could mock the fetch operation, especially since parallel sagas are also running in the app.
If there's any. Im not really into web technologies, but have to understand some awful code written by someone else in Node.
All node.js apps are npm modules once you execute npm init. After that point, you can publish the module by executing npm publish assuming you gave it a unique name in the package.json.
If the app isn't meant to return anything, then there is no need to export anything. However, it's almost always worth exporting something to allow for unit testing deeper than just starting the app as an http server and sending it requests.
It is also sometimes useful to modify the way your app runs based on whether it is being required as a module or executed as an app. For example, say i have an express rest api server. I can run it as a standalone server on api.example.com, and then require it into another application and run it from that application directly to avoid CORS issues without having to duplicate code or deal with git submodules, instead I simply npm install the api into the application that needs it and attach it just like you would a router. www.example.com/api
app.use('/api', require('#myusername/api.example.com'))
Going to run Karma+Jasmine to test angularjs client with real backend. Since Karma is using its own express but I need to access real nodejs backend with DB and other stuff, I'm thinking on adding interceptor into $httpProvider.interceptors that will just replace my calls to /api and redirec them into real backend location. Is there a better way?
You don't want to do that on unit tests (and personally I wouldn't even do that with E2E tests).
When doing unit tests, the $httpBackend get swapped with a dummy version that is not capable of doing real requests. That is intentional. You shouldn't do any test with the real backend.
On the other hand, there are E2E tests (where you test all your system together) where you could use the real backend in your tests (there are people who likes that, people who doesn't).
Keep in mind that unit test are all about units in isolation, that means that you don't care about dependencies and much much less about a backend.