Hello, I am following this example to implement m...
# pact-jsz
Zied Bejaoui
04/04/2024, 8:48 AMHello, I am following this example to implement my first PACT tests for kafka queues : https://github.com/pact-foundation/pact-js/blob/master/docs/messages.md
My question here is about theses two functions used respectively in consumer and provider tests : dogApiHandler and createDog.
According to pact best practices should I create theses functions as part of my test code or should I use existing functions available in my SUT codebase? Also I suppose that my test should not be connected to any real kafka as it should be mocked right?
đź‘‹ 1
m
Matt (pactflow.io / pact-js / pact-go)
04/04/2024, 9:24 AM
Ideally, the SUT should be what’s tested. Sometimes, you need to write some additional test code to wrap the internal behaviour and that’s (probably) OK. If you always try to think of Pact tests as unit tests, and that they should break if the external behaviour changes, then you are probably on the right track.
and that’s correct, you do not talk to the real kafka in the test
z
Zied Bejaoui
04/04/2024, 9:26 AMGreat! Thanks Matt for confirming this.
đź‘Ť 1
Zied Bejaoui
04/04/2024, 2:05 PMHi again, got a more precise question on implementing the same example please. Taking account this code for instance :
describe("receive transfer event", () => {it("accepts a transfer", () => {return messagePact.given("a new transfer").expectsToReceive("a request for a new transfer").withContent(transferBodyExpectation).withMetadata({queue: like("transfers"),}).verify(synchronousBodyHandler(actionHandler));});});});actionHandlertransferBodyExpectations
Slackbot
04/04/2024, 2:05 PMm
Matt (pactflow.io / pact-js / pact-go)
04/05/2024, 2:28 AM
yes that seems reasonable
Matt (pactflow.io / pact-js / pact-go)
04/05/2024, 2:28 AM
i.e. refactoring
actionHandler