This message was deleted.
# general
s
This message was deleted.
blobwave 1
y
The general advice for pretty much all classes of unit testing (and probably further up the stack) is to test in the codebase of the code being tested. For a variety of reasons, but the main over-riding one for Pact is that you want your contracts to change as an artefact of running tests on the changed code, The further away this test, the slower the feedback loop, the greater cost of change, and the potential for expectation drift (that which you present to the provider, and that of which your consumer code actually performs)
ps. Generally I wouldn’t preface questions with a quick question, as it is subjective to the reader to whom you are asking, and it may put them off.
Quick answer would be no Slightly longer answer, would be yes, its perfectly possible, but wholly unrecommended then reasons above
👌 1
m
If you think of a Pact consumer test as a unit test of your API consumer, then you can see why it wouldn’t make sense to do it that way (a centralised repo)
💯 2
b
Quick question, long answer yay
😆 2