Trying to write my first pact tests and I am not able to find answers to basic questions. Does consumer test and provider tests runs against mock servers only or should we be building our application locally (or on specific environment during CI/CD) and then run test against actual running application? Also, Is it possible for me to run consumer test against mock server and run provider tests against actual https endpoint?
This page answers all of those questions: https://docs.pact.io/getting_started/how_pact_works
Does consumer test and provider tests runs against mock servers only or should we be building our application locally (or on specific
environment during CI/CD) and then run test against actual running
application?
Consumer test: runs against a mock provider.
Provider test: pact simulates the consumer against a provider (see [3])
Is it possible for me to run consumer test against mock server
The consumer test must run against a Pact mock service, because that's how we record what you did and check that your requests match what's documented.
and run provider tests against actual https endpoint?
You can do this sort of "black box" approach, but better to run against a locally running provider that you can control.
Related
I have inherited an application at my job that is being converted from WCF to SignalR. It is a windows service created using Topshelf. When the service is started is connects to a SignalR hub. Various things may happen, such as a user sending a request to my service through the hub. Then my service will send back a request for their PIN. They send that back and my service then requests if they have authority to do their original request from yet another client. All of these various requests are interfaced of course.
Previously this was all done with WCF and we had a very comprehensive suite of tests for the service. Now that I am trying to switch all the tests over to SignalR I have no idea really where to even begin. Running any test starts the topshelf service as expected, but then of course it tries to connect to the hub which doesn't exist.
I have tried using Moq to simulate the hub, but it doesn't seem to work as mocking a running hub so of course I cannot get my service to connect to a mocked hub while the test is running. I'm not sure if that is a Moq limitation, or just me not understanding how to use it. I have also tried entirely recreating the hub as another project in the same solution as my service and testing project, but again I can't figure out how to actually make the hub run properly so that my service can connect to it when the test is running. Again, I assume that is my lack of knowledge. Our SignalR hub is created using the basic OwinStartup/MapSignalR process (just as in the microsoft chat app tutorial).
I feel like I'm going in a bunch of different directions and not getting anywhere because I don't know enough about SignalR and how to test it. I have done the basic "chat app" tutorial and the related tutorial about testing that with Moq, but once I try to add in the additional complexities of my project I just get lost.
What is need is for a test to run, "connect" to the SignalR hub, and give me a way to simulate the user request, and the user sending back their PIN, and the other client that sends back the authorization granted/denied message. All of the tutorials I find are for testing one single back and forth in that chain. I hope this all makes sense and someone can point me in the right direction of what I need to do to proceed. Thank you!
I have tried to recreate a hub within my project purely for testing, and I have tried setting up a Moq'd hub to connect to. I am expecting (hoping) to get a SignalR hub (real or mocked) that my service can connect to and do all of the various back-and-forths it needs to to test whatever it may be I am testing, for example the entire path of a user requesting to do something that they then have to authenticate with a PIN to do. So, not testing one method of the hub but a whole end-to-end process.
I have a Serverless stack (AWS) using API Gateway authentication and a Lambda, implementing a restful API using NestJS.
I'm using Serverless-offline to simulate the stack in my local environment. This allows me to simulate the API Gateway authentication (simple keys, not custom authorizer) and lambda execution from an end to end API call perspective.
I can use the NestJS test helpers to perform e2e tests, which allows me to inject mocks for other services not available in the stack.
What I'd like to do is use serverless-offline to run the tests - hence allowing me to test authentication via its simulated API Gateway. I can see how I can do this by launching serverless-offline in my tests (e.g. https://dev.to/didil/serverless-testing-strategies-4g92).
BUT, if I use serverless-offline (as link) then I can't see how it would be possible to inject mocks for other services not available in the stack.
Is there another solution for e2e testing that allows me to simulate the api gateway AND inject mocks?
Any help much appreciated!
With the testing strategy you linked you can mock your requests and responses to external services to test different scenarios. Nock is a library that can simplify mocking external requests in your tests.
Although, it seems that this may not be work as a I imagine with serverless-offline. I found this answer that outlines a strategy for replacing endpoints that access external services when running tests.
"Trusted" and "Privileged" server environments are frequently mentioned in the docs for Firebase, but there's no formal definition. What are they?
How do I make my server trusted or privileged?
While what "priveleged" or "trusted" server environments are is not explicitly searchable (prior to the creation of this Q&A), it can be inferred from the following excepts.
In the docs for FCM setup, is the following excerpt:
The server side of Firebase Cloud Messaging consists of two components:
The FCM backend provided by Google.
Your app server or other trusted server environment where your server logic runs, such as Cloud Functions for Firebase or other cloud environments managed by Google.
Your app server or trusted server environment sends message requests to the FCM backend, which then routes messages to client apps running on users' devices.
And in the docs for general setup:
Firebase projects support Google service accounts, which you can use to call Firebase server APIs from your app server or trusted environment. If you're developing code locally or deploying your application on-premises, you can use credentials obtained via this service account to authorize server requests.
Important to notice is that both explicitly say "app server or trusted environment" which implies the two are different things.
Further, the first excerpt (though somewhat semantically ambiguous)
that examples of trusted environments are "Cloud Functions for Firebase or other cloud environments managed by Google."
Finally,
in the second excerpt is the information "If you're developing code locally or deploying your application on-premises, you can use credentials obtained via this service account to authorize server requests"
From all of this it can be inferred that:
Trusted and Priveleged Environments are generally things internal to google and therefore intrinsically trustworthy
App servers are generally anything which has access to the right credentials
And finally, you do not need to take any steps beyond having the correct credentials to make your server a "Trusted Environment." It does not need to be a "Trusted Environment," because what that term really means is "Owned by Google."
A trusted environment is an environment where you control what code runs on it. In the context of apps built using Firebase, this sets them apart from the devices your regular app runs on as malicious users can take your app configuration data and run their own code with that.
I often explain trusted environment, as:
Your development machine, since you're usually the only one working on that.
A server (or VM, container, etc) that you control. Only you (and people you trust) should have access to the server, so shared servers are not a good fit.
Cloud Functions, since only collaborators on your Firebase project can deploy code there.
I am trying to test run a basic .NET web application on pivotal cloud foundry. This web application uses as its database a MongoDB server hosted on my local machine. At the moment I am limited to use of the cloud infrastructure by using just the Apps Manager.
I have read the pivotal cloud foundry docs about user provided services, but cannot figure out as to how the connection is to be really made. I have already come across various other ways like using MongoDB as a service (beta version), but at the moment I am not allowed access to the Operations Manager. Looking for an explanation on user provided services or how to implement the service broker API, specifically.
I am new to Mongo as well, so any suggestion regarding making a connection through tweaking Mongo may help as well. Thanks
The use case you describe (web app in PCF connecting to a resource in your local machine) is not recommended.
You can create a MongoDB instance for development purposes in PCF.
$ cf marketplace
...
mlab sandbox Fully managed MongoDB-as-a-Service
...
You can create a mlab service and bind it to your application. You will then have a MongoDB instance in PCF that you can use for development purposes.
Edit:
In that case a user provided service might help you, where you pass in your remote MongoDB instance configuration that you can read in your application. e.g.:
cf.exe cups my-mongodb -p '{"key1":"value1","key2":"value2"}'
You can add your local mongo-db as a CUPS service to your PCF Dev.
Check out the following post.
How to create a CUPS service for mongoDB?
We have an application that is running on Heroku and uses Firebase for data. There are some instances where we have to do some logic that require multiple nested Firebase calls (if method 1 succeeds, create object with method 2) and so on. Unfortunately, they seem to be a little more in-depth than what a transaction method on the client side could accomodate.
We are relying on the REST api to do these functions server-side, but have run into issues when stress-testing that they are frequently timing out (especially when issuing a PATCH request).
However, if we run the same test on a different server with the same code and Firebase database, they succeed no problem.
Is there any throttling going on for multiple requests from the same environment?