I show different approaches here. Which one are you talking about? The teskits aren't a generic tool, and depends on how you write your microservices, usually it'll be the same tool.
This talk is about the different alternatives. The idea is to give a closed Testkit without the consumer knowing the internal and being able to change the internals while the consumer can still run the tests and this will allow us to know if anything is broken.
17:22 this is not boom. And everything is Ok with test doubles. You just forgot to add test for case then user is blocked, find this place and fix it. You had to add this test to client service (method renderConfigurationPage ), see what it returns and repeat this result in your main e2e. So This is not about approach this is about lack of experience in tests and wrong mocked data.
@@user-ll2xw7tn6v The logic meant here is: after a user has been blocked it cannot be queried any more. When done solely with the stubs, everyone who configures these stubs is supposed to configure this interplay for his/her test cases. Even worse, if after some time, the service provider changes the logic (i.e. the user data can be queried even if the user itself is blocked) everyone will have to reconfigure his stubs configurations
Awesome idea.
I expect Testkit can be adjusted even to monolith architecture when I mock persistence layer.
awesome video thanks
Tldr. Just do integration contract testing using tools like Pact. Thanks
Which tool is used for micro services testing sir
I show different approaches here. Which one are you talking about? The teskits aren't a generic tool, and depends on how you write your microservices, usually it'll be the same tool.
Doesnt testkit leak the implementation to the consumers? Like isActive?
This talk is about the different alternatives. The idea is to give a closed Testkit without the consumer knowing the internal and being able to change the internals while the consumer can still run the tests and this will allow us to know if anything is broken.
17:22 this is not boom. And everything is Ok with test doubles. You just forgot to add test for case then user is blocked, find this place and fix it. You had to add this test to client service (method renderConfigurationPage ), see what it returns and repeat this result in your main e2e.
So This is not about approach this is about lack of experience in tests and wrong mocked data.
The idea is that this logic will be implemented once by the service provider and not by each one of the clients.
@@MaximNovak what logic are you taking about, which should be implemented by provider?
@@user-ll2xw7tn6v The logic meant here is: after a user has been blocked it cannot be queried any more. When done solely with the stubs, everyone who configures these stubs is supposed to configure this interplay for his/her test cases. Even worse, if after some time, the service provider changes the logic (i.e. the user data can be queried even if the user itself is blocked) everyone will have to reconfigure his stubs configurations