PACT
Integrated tests are a scam—a self-replicating virus that threatens to infect your code base, your project, and your team with endless pain and suffering
-jb rainsberger
Consumer driver contracts ?
Who is an API Consumer
Consumer Driven Contracts is a pattern or methodology where contracts between inter-dependent services are designed from the perspective of a service consumer. The contract for the interaction is developed by the consumer of a service.In business terms this is usually described as ‘putting the customer first’ or ‘listening to your customers.
The benefits to this approach are that you know who all the consumers of your service are, you’ll know when you make breaking changes so it is easier to make changes and the contract is also a form of documentation. Secondly, you’ll know exactly what functionality needs to be provided so you can implement the right services needed by your consumers and can follow the YAGNI principle
YAGNI: is a principle of extreme programming (XP) that states a programmer should not add functionality until deemed necessary.XP co-founder Ron Jeffries has written: "Always implement things when you actually need them, never when you just foresee that you need them." Other forms of the phrase include "You aren't going to need it" and "You ain't gonna need it".
How to start ?
1) The development of the interaction starts from the consumer side, hopefully with a test. The consumer team defines the contract for the interaction.
2) In provider verification, each request is sent to the provider, and the actual response it generates is compared with the minimal expected response described in the consumer test.Provider verification passes if each request generates a response that contains at least the data described in the minimal expected response.This contract is then provided to the provider team (in some cases it is the same team) and the provider service is implemented to fulfill the contract.
Pact tests should be data independent. Pact tests are best when successful verification doesn’t depend on the specific data that the provider returns
How to implement?
Check out the implementation guide
In the next article I will try to show an example of pact testing , till then let's get our head around Pact Testing
References:
https://www.youtube.com/watch?v=KwpDu9SuAbI
https://dius.com.au/2016/02/03/microservices-pact/
-jb rainsberger
Consumer driver contracts ?
Who is an API Consumer
Consumer Driven Contracts is a pattern or methodology where contracts between inter-dependent services are designed from the perspective of a service consumer. The contract for the interaction is developed by the consumer of a service.In business terms this is usually described as ‘putting the customer first’ or ‘listening to your customers.
The benefits to this approach are that you know who all the consumers of your service are, you’ll know when you make breaking changes so it is easier to make changes and the contract is also a form of documentation. Secondly, you’ll know exactly what functionality needs to be provided so you can implement the right services needed by your consumers and can follow the YAGNI principle
YAGNI: is a principle of extreme programming (XP) that states a programmer should not add functionality until deemed necessary.XP co-founder Ron Jeffries has written: "Always implement things when you actually need them, never when you just foresee that you need them." Other forms of the phrase include "You aren't going to need it" and "You ain't gonna need it".
How to start ?
1) The development of the interaction starts from the consumer side, hopefully with a test. The consumer team defines the contract for the interaction.
2) In provider verification, each request is sent to the provider, and the actual response it generates is compared with the minimal expected response described in the consumer test.Provider verification passes if each request generates a response that contains at least the data described in the minimal expected response.This contract is then provided to the provider team (in some cases it is the same team) and the provider service is implemented to fulfill the contract.
Pact tests should be data independent. Pact tests are best when successful verification doesn’t depend on the specific data that the provider returns
How to implement?
Check out the implementation guide
In the next article I will try to show an example of pact testing , till then let's get our head around Pact Testing
References:
https://www.youtube.com/watch?v=KwpDu9SuAbI
https://dius.com.au/2016/02/03/microservices-pact/
Comments
Post a Comment