Skip to main content

Posts

JSON Server: Rest API

I get that a lot that there are so many folks especially college students who struggle to find Rest APIs where they can play not only with the GET but with POST, PUT, DELETE methods too. The JSON Server is a popular and handy tool that lets you play with the mock REST APIs. It helps you to set up a REST API with CRUD operations very fast. Please go through this link to know more about it: https://github.com/typicode/json-server From set-up >> installation >> usage- everything is so simple. I recommend to use it along with the faker library to make it more effective: https://github.com/Marak/faker.js , like by creating a js file to inject the fake data: module.exports = () => { var faker = require("faker"); const data = { users: [] } // Create 50 users for (let i = 0; i < 50; i++) { data.users.push({ id: i, name: faker.name.findName(),email:faker.internet.email(), zipCode: faker.address.zipCode()}) } return data } Here's th...

RestAssured Vs Karate

RestAssured Vs Karate Initial Score: Rest Assured 0- Karate 0 1) RestAssured is really good but there is no built-in way to do a full equality match of a JSON payload in one step (not talking about extracting a particular field out of the response JSON). Contrary to this, Karate offers full JSON Comparison with so much ease (as shown in the first image below). And in case you have some node that shows dynamic value then you can simply ignore it by using hashtag # ignore for that node (as shown in the second image below). Note* There is no direct command to compare the whole response in RestAssured at once but we can still use JsonPath to parse the JSON file into a Map and then compare it with Hamcrest Matchers. Current Score: Rest Assured 0- Karate 1 2) Ease of using matchers: The powerful matching logic of Hamcrest is unbeatable in Rest Assured. Of course, we can use RegEx and Macros in Karate for the match but you need to learn that first. Final Score: Rest Assured 1...

What topics should we cover if we are planning to appear for an SDET Selenium/Java position (Exp 4-9 years)?

Here are the topics that we should prepare if we are planning to appear for an SDET Selenium/Java position (Exp 4-9 years): Iteration in Java Abstract Class Vs Interface Strings in Java Static Usage in Java Exceptions in Java HashMap in Java Java Annotations Master to Build your own XPATH and CSS Implicit, Explicit and Fluent Waits Handling Frames Data-driven testing using Excel JavaScript Executor Logs Generation (Logging infrastructure with Log4j) Advanced Reporting (Extent, Allure, Klov Report Generation) TestNG Framework Design Pattern (Page Object Model, Fluent, Singleton- Any 1 should be fine) Selenium Grid And finally: BDD Using Cucumber  Build Management with Maven and/or Gradle Git, GitHub, etc. Continuous Integration with Jenkins, Azure DevOps, Team City, etc. (Any 1 should be fine)

package.json in any node JS project

What is package.json in any node JS project? package.json is the heart of any Node.js project. Every Node JS project should have this file at the root directory. This file lists: • All the packages/modules needed for a Node JS project and their requested versions. • Several different directives or elements that tell NPM “How to handle the project” like scripts that can be run to automate tasks within the project. • All the metadata for a project, such as a name, the author, the license, etc. It makes your build reproducible, and therefore easier to share with other developers. In Simple words , if you have worked on any Java/Maven project- what pom.xml is for maven project; is the same as what package.json is for any Node JS Project. How we can generate it (package.json)? 1. Using “npm init” : Running this command (‘npm init’) will set up a new NPM package. On initializing, you will be prompted to enter a few answers. Once you answer those and if it worked successf...

Lesson learned from API Testing

Of course, we should ensure that even our basic API tests are built to cover "Triple S" checks i.e. Status code, Schema, and Scenario checks but when we test our APIs, we should NOT just focus on the request and response part of our APIs but most importantly we should understand that how application(s) are going to consume our APIs. This will definitely give you a solid set of additional use cases from an end-user point of view to cover all your bases.

Test Data Strategies in test automation

Your test results are mostly as good as the test data it consumes. What should be our Test data cleanup strategy in automation? -> Should we clean up the data immediately after each and every run? OR, Should we perform the clean slate periodically? It's hard to find one strategy that can solve all our test data issues in our automation suite. So, instead of focusing on finding that silver bullet, think thoroughly about your own test requirements and see which strategy can bring in max stability in your automation suite instead of following blindly what others are doing. I know you are still not sure that which particular strategy is right for your automation suite or not? Don't rush, after a few tests run your test suite itself will let you learn by generating issues like flaky tests/intermittent failures, false positives, slowness/performance issues, etc. etc. Please go through this well-crafted article on "Test Data Strategies" by @Joe Colantonio/@P...