pact-foundation / pact-net Goto Github PK

There is currently a thread safety issue in the consumer debug logging when a test suite contains multiple mock providers and the tests are run in parallel.

To work around this temporarily, disable parallel test execution. However a fix will be released very soon.

Hi Guys,

Where can I find samples of how to create the pact file with types instead of fixed values?

I wan tot use this in a project, but I won't be able to unless I can find a way to work with types instead of fixed data.

Thanks,

Karl

Hi,
I had the last Nancy 1.4.3 and the consumer test was raising an exception (timeout on the ClearInteractions). I have checked all other dependencies but it fails because of Nancy: it works with the 0.23.1. I did not check with other versions. At least you should update the documentation.

Btw, thank you for this very nice library.
Xavier

We are currently running the setUp and tearDown functions at the start and end of the provider verification process. This should actually be run for each interaction within the verification process.

I am digging to achieve something similar and looking if there is any .net core version of pact?

Hi. I'm struggling with generating pact file. Either I set PactDir path manually or leave it as default, .json file is not being created. However log file is generated successfully every time. I run test within Resharper and it passes. Any idea what might be wrong?
PactBuilder = new PactBuilder(new PactConfig { PactDir = @"..\..\pacts", LogDir = @"..\..\logs" });

Based on PR31, @bethesque and I have had a discussion about request handling and updates have been made to the spec to clarify the implementation. We need to update the request handling logic to match the clarifications in the spec.

I was trying to verify a json response that contained a list of about 50 objects and kept getting above error

Easy fix is to increase the _comparisonPasses in HttpBodyComparer.AssertPropertyValuesToMatch but was wondering if there is a better approach.

Is there a way to test against a particular expected schema instead of hard coded values for the service results in say a Json Schema way? e.g. This array will exist and not be empty, this string will be n characters long, this property will be null, etc.

HI there
I've recently spent some time grappling with mysterious error messages and persuading a solution to build. I didn't find anything on the internet about it, so I thought I would report it here.
When I first added Pact.Net to my solution everything went very smoothly. I then came back to it a few weeks later, I think having changed absolutely nothing and it wouldn't build. The error messages in visual studio are basically meaningless, but there is something a tiny bit more useful in the build output, as follows:
The primary reference “blah.dll” could not be resolved because it has an indirect dependency on the framework assembly “System.Net.Http, Version=2.2.28.0, Culture=neutral, PublicKey Token=b03f5f7f11d50a3a” which could not be resolved in the currently targeted framework. “.NETFramework, Version=v4.0”. To resolve this problem, either remove the reference “blah.dll” or retarget your application to a framework version which contains “System.Net.Http, Version=2.2.28.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a”
After a lot of fiddling it turns out that you need to nuget install-package Microsoft.Net.Http 2.2.28.0 on all projects that reference a project, that contains a reference to pact.net.
This isn't the latest version of the library, and looking at the Pact.Net source there are no "Use Specific Version" references to this, so it's all a bit confusing. I think it might be because the Microsoft.Bcl package references System.Net.Http, but I didn't get to the bottom of it.
Cheers
Cedd

At the moment there is a couple of problems with current 'verify all interactions in one test' approach:

• it's tricky to debug since there is no easy way to isolate test scope to one particular interaction
• developers need to remember that mocks and expectations need to be reset in teardown action for interaction - would be nice to be able to follow conventions of used test frameworks

Having this feature will be very useful for us. We are planning on building the regex matching to conform with the v2 spec gist.

Create nuget package and publish to nuget.org feed, we may also decide to IL merge or include the thirdy party assemblies as resource rather than nuget dependencies.

We recently started using pact-net at work and I'm slightly bothered by how much manual work is involved in creating the mocks and handling the resulting files.

I was thinking whether it would be a good idea (and whether someone thought about it) to create some sort of proxy generic mock which could be started in "record mode" and to which we would then direct our services. This proxy mock would (based on a config file) forward the requests to the actual service and then transport the response back to the actual service. This request/response interaction pair could then be saved as, e.g., a JSON file. Then, we would be able to start the proxy mock in a "replay mode" where it's simply replying to requests based on what it has recorded. This way we would avoid having to write the mock services ourselves and instead take the current snapshot of the provider as the "valid contract" upon which we base all our future test runs.

Has anyone thought about this? Do you see value on it if, e.g., I was to work on something along these lines?

Not sure if the .net implementation covers this, so raising an issue to ensure it gets addressed if it hasn't already.

For example, it should not be possible to specify that a phone number must match /^\d+$/, but give an example of "foo".

Hey @neilcampbell, question - would it make sense to run a match on request body even if request body for registered interaction is not specified?

Currently library will consider two requests matching even when body of the actual request is completely different (i.e. not null) from request body for registered interaction (that is null).

Have a discussion about if we want to use TC or use something like travis-ci.org? We could also generate a hook to auto publish to the nuget.org package feed, when commits have been merged into master.

I noticed that you're using System.Net.Http.HttpClient in your examples. Is RestSharp supported as an alternative client library?

I've noticed that the default serialization settings for the request body currently do not serialize null values.

Some rest clients, however, notably RestSharp, do serialize null values and do not directly give you the option to change these settings. You can get over it by serializing manually using something like JSON.NET in your client.

Could we possibly be able to tweak the serialization settings so that a body can match based on the preferred serialization settings of the app, rather than PACT's preferred settings? Not sure whether you think this is a good idea....

Ensure that query params are correctly encoded etc

Going back to pull-request #71 I have managed to recreate a similar issue, I have created a repository here

When running the test I get the error message:

System.IO.FileLoadException : Could not load file or assembly 'System.IO.Abstractions, Version=1.4.0.86, Culture=neutral, PublicKeyToken=d480b5b72fb413da' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
at PactNet.Infrastructure.Logging.LocalRollingLogFileMessageHandler..ctor(String logFilePath)
at PactNet.Infrastructure.Logging.LocalLogProvider.AddLogger(String logDir, String loggerNameSeed, String logFileNameTemplate) in C:\projects\pact-net\PactNet\Infrastructure\Logging\LocalLogProvider.cs:line 36
at PactNet.Infrastructure.Logging.LocalLogProvider.AddLogger(String logDir, String loggerNameSeed, String logFileNameTemplate) in C:\projects\pact-net\PactNet\Infrastructure\Logging\LocalLogProvider.cs:line 37
at PactNet.Infrastructure.Logging.LocalLogProvider.AddLogger(String logDir, String loggerNameSeed, String logFileNameTemplate) in C:\projects\pact-net\PactNet\Infrastructure\Logging\LocalLogProvider.cs:line 37
at PactNet.Infrastructure.Logging.LocalLogProvider.AddLogger(String logDir, String loggerNameSeed, String logFileNameTemplate) in C:\projects\pact-net\PactNet\Infrastructure\Logging\LocalLogProvider.cs:line 37
at PactNet.Mocks.MockHttpService.Nancy.NancyHttpHost..ctor(Uri baseUri, String providerName, PactConfig config, Boolean bindOnAllAdapters) in C:\projects\pact-net\PactNet\Mocks\MockHttpService\Nancy\NancyHttpHost.cs:line 27
at PactNet.Mocks.MockHttpService.MockProviderService.<>c__DisplayClass13_0.<.ctor>b__0(Uri baseUri) in C:\projects\pact-net\PactNet\Mocks\MockHttpService\MockProviderService.cs:line 45
at PactNet.Mocks.MockHttpService.MockProviderService.Start() in C:\projects\pact-net\PactNet\Mocks\MockHttpService\MockProviderService.cs:line 129
at PactNet.PactBuilder.MockService(Int32 port, JsonSerializerSettings jsonSerializerSettings, Boolean enableSsl, Boolean bindOnAllAdapters) in C:\projects\pact-net\PactNet\PactBuilder.cs:line 78
at PactNet.PactBuilder.MockService(Int32 port, Boolean enableSsl, Boolean bindOnAllAdapters) in C:\projects\pact-net\PactNet\PactBuilder.cs:line 58
at PactNetTests.ContractTest.SetUp()

Remove it ...

I am trying to point my PactVerifier to a Pact-broker endpoint protected by basic auth. I am able to access the endpoint using any rest client (postman) by passing the credentials in the URL.
http://user:pass@pact-broker/---

But when I use the same URL in the PactUri method and then call Verify, it gives me a 401.

Looks like the HttpClient that is newed up in the PactVerifier doesn't like the credentials passed in the PactUri. Also, since the constructor is internal, there is no way to externally inject the httpclient with configured auth header.

Any ideas/examples of how we can use the pact-broker behind basic auth security?
Any help is highly appreciated. Thanks

Thank you for building the pact-net.
Just a small enhancement request.
If the description in the Verify method does not exist in the pact file, currently no feedback is given.
Please enhance so that either it fails the test or prints a warning.
Thank you.

Currently if you setup a POST with a body but forget to set the content type it will give unclear messages as to why the interaction does not match.

Either add as a Git submodule or just update the subtree to include newly added response specification tests

Add the doc xml file (I know people don't like writing code comments)

The doc xml file can be used to provide intellisense support - especially useful for getting people running quickly. I (personally) find adding these things early on the project make them easier to maintain than adding them at the end.

When using MockProviderNancyBootstrapper it needs the PactConfig.LoggerName to be set and it can't be set when creating PactConfig in an external assembly because it's currently set to be internal.

Add test cases for:

• Get event by id
• Get events using a query string

The current test output mechanism is fairly primitive and could be a lot better!

I would be nice to use a Reporter abstraction and come up with a nice way of reporting failures. BDDfy may be a good place to start for inspiration.

You can use the .gitignore to exclude the packages from being included in the repository but still keep the repositories.config in the repo. e.g.

/packages/*
!packages/repositories.config

100% if my .net c# integration is done through 'service references' and SOAP messages.
I tried to use pact-net with no success. Is it supported? Will it be? What has to be done? Nothing in readme...

There is some nasty static stuff on the MockProviderNancyRequestDispatcher, which basically means that Parallel tests will fail. We cannot use ThreadStatic as the request dispatcher will run in the nancy thread and the state will not be setup correctly for the test.

We can either:

1. Hold a collection of expectedRequest/Responses
2. Remove static state all together in some way (preferred)

Provide a mechanism to verify if the provider was called in the way we expected during the test. The ruby library also looks to allow configuration of verifications, so it may be a nice extension point too.

If developer forgets to specify status code, it's quite tricky to figure out what's going on, as mock server simply does not respond to the request.

new ProviderServiceResponse
{
    Headers = new Dictionary<string, string>
              {
                  {"Content-Type", "application/json"}
              },
    Body = new
           {
               firstName = "Bob"
           }
}

Would be useful to output exception message (that is likely to be in the response) if consumer expects 201, but there was an error and provider returned 500

Hello, I am working on generating a pact file at the moment, which works fine when I run my tests in my project from Visual Studio. However, when I run those same tests from the command line as an administrator, no pact file is generated. I was hoping this could work from the command line (currently using MsTest.exe) so the build process could generate a pact. As a side note, the pact file would normally generate under the folder Api.Tests, which I assume is because it is the root folder of my test project. Any insight on this would be appreciated.

Thanks!

Currently PactNet allows identical interactions to be added by a user, which creates issue in identifying an interaction uniquely.

Haven't thought a lot about this yet - but has anyone got PACT working with access/identity tokens in headers?

Consumers will have tokens in the request headers, but ensuring they remain valid on the provider side in tests.

Is there anyway of replacing the token in the pact request on the provider side?

Currently we can only specify a pact file location on disc. It would be nice to use some kind of broker mechanism for resolving pact files and publishing pact files to.

xUnit 2 redirects the console and therefore there will be no console output when using it.

http://xunit.github.io/docs/capturing-output.html

Hi Guys,

I have a JSON pact file with href links that is part of the response body from the consumer. Which looks something like this:

"links": [
{
"rel": [
"self",
"paymentDetail"
],
"href": "/api/uk/account/12345/payment-detail"**
}
]
},

However the provider responds with the full resource as below:

"href": "http://localhost:12345/api/uk/customeraccount/123456/payment-detail"

Therefore when I run the provider test and it compares the actual to expected it fails. I am using Pact. Net version 1.1.0 which does not support partial matching as of yet. Is there a work around that anyone knows off that could assist me in which the consumer can ignore the server name?

Regards,
Newbiee

Hi,

I'm trying to build pacts that have randomly generated unique IDs in the path. Example:

  "request": {
    "method": "get",
    "path": "/groups/d6a61741-203a-4b8a-aec1-c9db15cff87b/messages/8a975ddf-1786-48a8-b835-8f7f578afbf1/locations",
    "headers": {
      "Accept": "application/json"
    }
  },

Is this possible to do this using PactNet? Does it matter that it is Pact 1.1 Specification - am I required to use Pact 2 Specification compatible tools/platforms for regular expressions to be part of the path? Or is it the case that the "path" can never be this dynamic, regardless of the Pact Specification version?

Thanks a bunch.
-Jon

Sorted - sorry

The 'readme' should provide a getting started guide and maybe even a sample to help users quickly get to grips with PACT (.NET).

It would probably be something very similar to the readme.md or even refer to the readme.md :)

I notice the pactnet.config and pactnet.pdb are not in the nuget package.

The PDB is useful for when a crash happens and users report a defect as you will get a full stack trace with line numbers making your life so much easier.

The config file has a lot of assembly binary redirects which may or may not be important.