Hello there! Me again!! We are closer to finishin...
# pact-net
a
Hello there! Me again!! We are closer to finishing our pilots with PactNet in my company. I'm very confident that we will have success! 🙏 However, one big issue that we are facing is related to the way that the .net apps are built on a provider side. In many cases, the apps expose one "API in memory" and appears the verification on a provider side needs to have a real instance with a specific port running the provider app. Is it a mandatory requirement? Is there any workaround for that? Thanks a lot 😉
🙌 1
m
Yes, that is a current requirement. I do think somebody in the community did find a workaround though, I’m not sure if that’s documented
a
Wow!!! It would be amazing, I'll look for it... but if I remember something, let me know too 😉
👍 1
@Matt (pactflow.io / pact-js / pact-go) related the example provided in pact-net... we realized that the data is injected in controller of providers... for example in this attached image. However, it's little intrusive in the apps. Correct? Is it mandatory? Is there any another way..? Or always the teams will need to adjust tests and also inject data in controllers? Thanks again and sorry for this quantity of questions.
Or is it only an example to set up a data provider during the execution and experiment with the solution?
m
This is a general question about provider states. Pact is agnostic to how you setup your test cases and data - you could seed a database, use stubs etc.
Sorry just on mobile, but perhaps it's worth looking at a few non .NET examples to get a feel for it
a
Yes @Matt (pactflow.io / pact-js / pact-go), I already saw other examples in languages such as python and java too... And I really understand provider-states, my question is specially related to the possibility of setup data, states, and the requests to providers only in a test project, without the need to inject code in a provider side (e.g controller).
m
I don’t think you should be changing your application architecture for the tests, if that’s what you’re asking?
You just need to ensure there is data for the tests, and if you need to setup data for states - then do that too. However you do that is really up to you. Pact is deliberately agnostic as to how this happens
a
@Matt (pactflow.io / pact-js / pact-go) Sorry for my delay! Thanks a lot for your explanation... Yes, my idea is not to change the architecture... its not make sense! In this week, me and my team will try to finish this poc 😉
👍 1
For now, we have just the problem with api in memory... We will try to expose the app using docker e redirect for one port to run the verification in a provider side....
👍 1
Hello @Matt (pactflow.io / pact-js / pact-go), how are you? In our context, we have several ways to inject data for many databases in multiple projects... However, it has been a little complicated to guide the teams around it. So, we were thinking about proposing that the teams just create database mocks (not the entire provider app, of course.) and inject data mocks in providers databases to surpass these issues. Is something wrong from your perspective? Did you see some projects implemented in this way? I was thinking about it, due to the data can stay outdated in real databases as well as in a mocked database (and this option can be easier to setup).