Trisha Chetani
Journey of me
Sunday, June 25, 2023
Monday, January 23, 2023
Contract Testing - Pact
I have to set up contract-based testing in my team and I took a course from a test automation university which I am sharing via a blog post.
Credits to : TAU, Rafaela Azevedo
Introduction
A contract test assures that services can communicate with one another and that a provider has fulfilled a contract that was anticipated by a service that is using it. Anywhere that two services can communicate with one another is where contract tests are applicable (an API with the front end, for example).
Contract tests may have a straightforward structure or a complicated one that involves numerous providers and consumers interacting. As is typical in a microservices design, the provider of one flow is frequently also the consumer of another.
Consumers and Providers
What do a provider and a consumer mean in this situation? Any party that offers a service for interactions with its dependents is a provider, and any party that uses an API to communicate with a dependent service is a consumer. A relationship between a consumer and a consumer can be seen in the interactions between various back-end APIs. Another example is the front end of a browser communicating with a back-end API.
Contracts
Consider a contract as a binding legal arrangement. A series of contacts with anticipated request and answer structures are represented by contracts.
Broker
Contracts are kept with a broker. Although any generic asset server will do, versioning support is preferred. Utilizing the open-source Pact broker, which is ideal for these specific requirements, is a viable solution. A bespoke factory broker can be created using Docker.
Contract hierarchy test
In the testing hierarchy, contract tests are located next to integration tests. There is a possibility to develop contract tests wherever the reliability of communications between services must be confirmed.
Integration tests versus contract tests
Contract tests have an advantage over integration tests in that they can be conducted without a full runtime environment. Tests can be done independently by interacting with mock consumers and providers to simulate real consumers and providers. Contract tests reveal issues with messages sent between services, whereas integration tests highlight issues with interactions between integrated units. This enhances system regression detection, warning programmers before errors are committed to providers or customers alike. Finally, contract testing enables users to create applications using API definitions before the provider API is formally finished.
End-to-end API tests versus contract tests
Functional testing from beginning to end will find inconsistencies that show up in output data or the user interface. Contract tests will only check that API endpoint connections are active and functioning correctly.
End-to-End tests, in contrast, take a lot of time to execute because they are rigorous and complicated in design. They frequently reveal important flaws that would otherwise go unnoticed. Although limited in scope, contract testing is less time-consuming and can be done more frequently to offer some level of smoke test coverage each time code is released.
Functional tests versus contract tests
Functional testing verifies that the anticipated system activity has taken place while contract testing concentrates on the messages that move back and forth between a customer and a supplier.
Using Pact to Mock Test Interfaces
Pact is a consumer-driven contract testing tool, which means that contracts are created while consumer tests are being run. The benefit of using this pattern is that it only allows testing of producer output that is really used. As a result, any provider behaviour that current customers do not use can change without affecting any testing.
You don't have to worry about Pact managing the mocking of provider and consumer objects or contract definitions. The test code is written using the test-driven development (TDD) methodology. Pact simulates a request being sent to a real server by producing a faked answer. It creates a JSON file called Pact.
The Pact JSON file is loaded when a test is triggered on the provider's end, and a verification procedure decides whether or not the contract corresponds to what a customer expects. In line with consumer expectations, Pact creates this contract file, which will be compared to what the actual provider server is actually transmitting.
Languages that Pact presently supports include:
- Ruby
- Javascript
- .NET
- JVM
- Go
- Python
- Swift
- PHP
Sunday, September 4, 2022
Pairing with Sam Connelly on the journey of Public Speaking
https://twitter.com/BugHunterSam/status/1565219944484458498
After I got the response via this tweet, we DMed each other via twitter, and started to discuss the pairing.
We paired up on Sunday early morning and began talking about how we might pair up and what we could accomplish together.
Sam asked me a question at the beginning of our talk that I also believe is significant.
- Who is your audience? I mentioned testers.
- What you could give a talk on comfortably? Topics around testing and tools.
- Which one is my favourite? At the moment, I have to prepare for the super voice 3 round, so I thought I to choose the topic test strategy.
- What is the key takeaway? she further conveyed to me! Most people do not pay attention and they either listen to the start or the end. I replied to her, that maybe people could imply what I have done which I have shared during my talk! So she mentioned to me "Oh! Inspiration others do the same."
- Why would I bring in the audience to use this test strategy? What is the initial feedback?
Because we have grown up with stories, humans can relate to them. Keep in mind the Cinderella tales! In our context, What was the fix for this? brainstormed ideas Your encounter with the test technique, which initially did not function, was one of five different things that did not work. It's crucial to discuss failure. We tried to solve an issue in this way, but it didn't work, so we tried it in this approach instead, and it worked.
What makes a good presenter?
- Better context
- Include me in that conversation.
- Listening to it is interesting!
- Death by PowerPoint, often known as presentation slides with bullets, is terrible presentation material.
- the narrative you are telling.
Focus on the story you are going to tell. Pick a topic, and brainstorm everything you could talk about.
Then if you can pick five things from the list brainstorming. All down on the page. Big list of things, top 5 head.
Work together to generate five ideas related to the theme. Do you think using the five ideas you came up with will help me tell a story? Does not advance the plot? Rise and repeat.
Let's use mind maps. Brainstorming, its functioning, its collaboration, and use with the team, and its use of any tools. Each supporting topic for the major topic? There are five things connected to that that you should keep in mind when creating your slides. Focus on the story you're trying to tell, frequently a difficult one; if you're on a journey, describe it from the perspective of that point. Then, when you've created a story, You need nothing more difficult than this! 1 thought, 1 word on your slide. She further mentioned to me that this is Takahashi_method. It is not her style. Further, she added, that is recommended style which is less time-consuming.
We agreed on for our next meeting, we both present 2 to 5 minutes of presentations on a mind map. We both will give presentations. We discuss topic 1. What went well, and what could be improved?