Hi everyone, I have maybe a crazy question. I woul...
# general
s
Hi everyone, I have maybe a crazy question. I would like to overhaul our current integration testing system. Lets just say it is a publishing type system but interacts with http like System1 -> System 2 -> System 3 (system 1 takes input and publishes to system2), and some other external actor interacts with system 3 and we want to make sure those interactions are correct and the propagation from system 1 got to system 3. Right now its black box where we interact with system 1, wait a while, and then test and make sure system 3 responds with correct results. In my ideal world, we have scenario 1, it interacts with system1, knows what outputs system 1 should have when it interacts, and that is one test. We then take the exact output of that test and use it to test system 2 and so on. Right now when I look at bidirectional testing, it feels like it just makes sure the interfaces conform, but does not fully replace knowing if the output system 1 created is causing the right results in system 2. Is Pact maybe not the right tool for what I am trying to achieve (replace our end 2 end testing with service level tests) but trust that all the interactions that system1 generate cause the correct interactions in system2. Not sure if this is far too much info to get help on as well but looking for any guidance!
b
Sounds like you're talking about 2 different kinds of testing, and they both have value in different ways. I don't think you can get same kind of confidence from only one, and you should keep both separate: • Contract testing (consumer-driven) is still great value, and should give you high confidence in the individual interfaces. • Functional (across several boundaries) will give you the final sanity check, making sure that expected state translates through all the layers. This doesn't need to be so exhaustive, if you have the foundational confidence from the other tests. I'd stay away from bi-directional, unless you need it as a starting point to reduce implementation time, but it will slow you down in different ways.
šŸ‘ 1
s
Ya, I agree, I feel like I am trying to make our functional tests better and I was seeing if pact could help. However, obviously its designed for contract level testing here. Thanks for feedback.
šŸ‘ 2
b
Sounds like a good direction šŸ™‚ The goal isn't to replace everything with contract tests, it's to reduce the overhead of testing by doing the right kinds of testing in each place.
šŸ‘ 2