DEV Community: GREGORY BRANDON HUANCA MERMA

API Testing Frameworks Comparison: REST Assured vs Postman vs Playwright

GREGORY BRANDON HUANCA MERMA — Sun, 06 Jul 2025 05:15:12 +0000

API testing is crucial for ensuring your services work correctly. In this article, we'll compare three popular API testing frameworks with real-world examples.

Overview
REST Assured (Java)
Postman/Newman (JavaScript)
Playwright (TypeScript)
Comparison Table
When to Use Each

Overview

We'll test a simple Product API with these endpoints:

GET /products/{id} - Get product by ID
POST /products - Create new product
PUT /products/{id} - Update product

REST Assured (Java)

REST Assured uses a fluent API with Given-When-Then syntax, perfect for Java developers.

Setup

<!-- pom.xml -->
<dependency>
    <groupId>io.rest-assured</groupId>
    <artifactId>rest-assured</artifactId>
    <version>5.3.2</version>
    <scope>test</scope>
</dependency>
<dependency>
    <groupId>org.junit.jupiter</groupId>
    <artifactId>junit-jupiter</artifactId>
    <version>5.9.2</version>
    <scope>test</scope>
</dependency>

Basic Test Example

import static io.restassured.RestAssured.*;
import static org.hamcrest.Matchers.*;
import org.junit.jupiter.api.Test;

public class ProductApiTest {

    @Test
    public void testGetProduct() {
        given()
            .baseUri("https://api.example.com")
            .header("Authorization", "Bearer token123")
        .when()
            .get("/products/1")
        .then()
            .statusCode(200)
            .contentType("application/json")
            .body("id", equalTo(1))
            .body("name", notNullValue())
            .body("price", greaterThan(0.0f));
    }

    @Test
    public void testCreateProduct() {
        String productJson = """
            {
                "name": "Laptop",
                "price": 999.99,
                "category": "Electronics"
            }
            """;

        given()
            .baseUri("https://api.example.com")
            .header("Authorization", "Bearer token123")
            .contentType("application/json")
            .body(productJson)
        .when()
            .post("/products")
        .then()
            .statusCode(201)
            .body("id", notNullValue())
            .body("name", equalTo("Laptop"));
    }
}

Postman/Newman (JavaScript)

Postman provides a visual interface, while Newman runs collections from command line.

Collection Setup

Create a Postman collection with environment variables:

{
  "baseUrl": "https://api.example.com",
  "authToken": "Bearer token123"
}

Pre-request Script

// Get auth token if not exists
if (!pm.environment.get("authToken")) {
    pm.sendRequest({
        url: pm.environment.get("authUrl") + "/login",
        method: 'POST',
        header: { 'Content-Type': 'application/json' },
        body: {
            mode: 'raw',
            raw: JSON.stringify({
                username: "testuser",
                password: "testpass"
            })
        }
    }, (err, response) => {
        if (!err) {
            const token = response.json().token;
            pm.environment.set("authToken", "Bearer " + token);
        }
    });
}

Test Script

// Test GET /products/1
pm.test("Status code is 200", function () {
    pm.response.to.have.status(200);
});

pm.test("Response has required fields", function () {
    const product = pm.response.json();
    pm.expect(product).to.have.property('id');
    pm.expect(product).to.have.property('name');
    pm.expect(product).to.have.property('price');
    pm.expect(product.price).to.be.above(0);
});

pm.test("Response time is acceptable", function () {
    pm.expect(pm.response.responseTime).to.be.below(2000);
});

// Save product ID for next requests
pm.test("Save product data", function () {
    const product = pm.response.json();
    pm.environment.set("productId", product.id);
});

Run with Newman

# Install Newman
npm install -g newman

# Run collection
newman run collection.json -e environment.json --reporters cli,junit

Playwright (TypeScript)

Playwright offers modern API testing with excellent TypeScript support.

Setup

npm init playwright@latest
npm install @faker-js/faker

// playwright.config.ts
import { defineConfig } from '@playwright/test';

export default defineConfig({
  use: {
    baseURL: 'https://api.example.com',
    extraHTTPHeaders: {
      'Authorization': 'Bearer token123'
    }
  },
  reporter: [['html'], ['junit', { outputFile: 'results.xml' }]]
});

Test Example

// tests/product-api.spec.ts
import { test, expect } from '@playwright/test';
import { faker } from '@faker-js/faker';

test.describe('Product API Tests', () => {

  test('should get product by ID', async ({ request }) => {
    const response = await request.get('/products/1');

    expect(response.ok()).toBeTruthy();
    expect(response.status()).toBe(200);

    const product = await response.json();
    expect(product).toHaveProperty('id', 1);
    expect(product).toHaveProperty('name');
    expect(product).toHaveProperty('price');
    expect(product.price).toBeGreaterThan(0);
  });

  test('should create new product', async ({ request }) => {
    const newProduct = {
      name: faker.commerce.productName(),
      price: parseFloat(faker.commerce.price()),
      category: 'Electronics'
    };

    const response = await request.post('/products', {
      data: newProduct
    });

    expect(response.status()).toBe(201);

    const createdProduct = await response.json();
    expect(createdProduct.name).toBe(newProduct.name);
    expect(createdProduct.price).toBe(newProduct.price);
  });

  test('should handle not found error', async ({ request }) => {
    const response = await request.get('/products/99999');

    expect(response.status()).toBe(404);

    const error = await response.json();
    expect(error).toHaveProperty('message');
  });

  test('should validate response time', async ({ request }) => {
    const startTime = Date.now();
    await request.get('/products/1');
    const responseTime = Date.now() - startTime;

    expect(responseTime).toBeLessThan(2000);
  });
});

Run Tests

# Run all tests
npx playwright test

# Run specific test file
npx playwright test tests/product-api.spec.ts

# Run with UI mode
npx playwright test --ui

Comparison Table

Feature	REST Assured	Postman/Newman	Playwright
Language	Java	JavaScript	TypeScript/JS
Learning Curve	Medium	Easy	Medium
Setup Complexity	Medium	Easy	Easy
CI/CD Integration	Excellent	Good	Excellent
Reporting	Good	Excellent	Excellent
Parallel Execution	Yes	Limited	Yes
Data Generation	Manual	Manual	Built-in (Faker)
Debugging	IDE	GUI + Console	VS Code + UI Mode

When to Use Each

Choose REST Assured if:

Your team uses Java/JVM languages
You need complex test logic and assertions
You want strong IDE integration
You're testing Java microservices

Choose Postman/Newman if:

You need visual test creation
Your team prefers GUI tools
You want easy collaboration and sharing
You need detailed test documentation

Choose Playwright if:

You want modern tooling with TypeScript
You need both API and E2E testing
You want excellent debugging capabilities
You value fast execution and parallel testing

Example Repository Structure

api-testing-comparison/
├── rest-assured/
│   ├── pom.xml
│   └── src/test/java/ProductApiTest.java
├── postman/
│   ├── collection.json
│   ├── environment.json
│   └── package.json
├── playwright/
│   ├── playwright.config.ts
│   ├── package.json
│   └── tests/product-api.spec.ts
└── README.md

GitHub Actions CI Example

# .github/workflows/api-tests.yml
name: API Tests

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        framework: [rest-assured, newman, playwright]

    steps:
    - uses: actions/checkout@v3

    - name: Setup Java (REST Assured)
      if: matrix.framework == 'rest-assured'
      uses: actions/setup-java@v3
      with:
        java-version: '17'
        distribution: 'temurin'

    - name: Setup Node.js (Newman/Playwright)
      if: matrix.framework != 'rest-assured'
      uses: actions/setup-node@v3
      with:
        node-version: '18'

    - name: Run REST Assured Tests
      if: matrix.framework == 'rest-assured'
      run: |
        cd rest-assured
        mvn test

    - name: Run Newman Tests
      if: matrix.framework == 'newman'
      run: |
        cd postman
        npm install -g newman
        newman run collection.json -e environment.json

    - name: Run Playwright Tests
      if: matrix.framework == 'playwright'
      run: |
        cd playwright
        npm ci
        npx playwright install
        npx playwright test

Conclusion

Each framework has its strengths:

REST Assured excels in Java environments with powerful assertions
Postman/Newman provides the best user experience for manual and automated testing
Playwright offers modern tooling with excellent TypeScript support

Choose based on your team's skills, existing tech stack, and testing requirements. You can also use multiple frameworks for different types of testing in the same project.

[Boost]

GREGORY BRANDON HUANCA MERMA — Mon, 09 Jun 2025 19:42:20 +0000

GREGORY BRANDON HUANCA MERMA

Jun 8 '25

🧪API Testing with Postman: From Basics to Real-World Scenarios 🚀🚀

#programming #tutorial #opensource

Comments 3

7 min read

🧪API Testing with Postman: From Basics to Real-World Scenarios 🚀🚀

GREGORY BRANDON HUANCA MERMA — Sun, 08 Jun 2025 05:00:48 +0000

Introduction

In today's interconnected digital landscape, Application Programming Interfaces (APIs) are the unsung heroes, facilitating seamless communication between diverse software systems. Whether you're using a mobile app, interacting with a web service, or integrating third-party tools, APIs are the invisible backbone making it all happen. Given their critical role, ensuring the reliability, functionality, and performance of these APIs through robust testing is paramount.

While numerous tools and frameworks exist for API testing, Postman has emerged as a powerhouse, beloved by developers and quality assurance (QA) engineers alike for its intuitive interface, comprehensive features, and collaborative capabilities. This article will guide you through effectively leveraging Postman for API testing, moving beyond basic requests to explore real-world scenarios, practical code examples, and insightful conclusions.

Why Choose Postman for API Testing? 🤔

Postman has evolved significantly from its humble beginnings as a Chrome browser extension into a full-fledged API development and testing platform. Its widespread adoption is due to several compelling advantages.

User-Friendly Interface: Postman's graphical user interface (GUI) is incredibly intuitive, making it easy for beginners to send requests and inspect responses without a steep learning curve.

Code-Optional Start: You can begin basic API testing without writing a single line of code, making it highly accessible. As your needs grow, its powerful scripting capabilities allow for complex test scenarios.

Comprehensive HTTP Support: It supports all standard HTTP methods (GET, POST, PUT, DELETE, PATCH) and various authentication mechanisms (Basic, OAuth, Bearer Tokens, etc.).

Rich Feature Set: Beyond sending requests, Postman offers robust functionalities for writing automated tests, generating API documentation, monitoring API performance, and even simulating API responses with mock servers.

Collaboration and Sharing: Postman facilitates team collaboration through collections, environments, and workspaces, allowing seamless sharing of API requests and test suites.

Cross-Platform Compatibility: Available as a native application for Windows, macOS, and Linux, ensuring accessibility regardless of your operating system.

Getting Started: Your First API Request and Simple Validation 🏁

Let's kick things off with a fundamental API interaction: a GET request. We'll use the JSONPlaceholder API, a popular free fake API for testing and prototyping.

Launch Postman: Open the Postman desktop application.
Create a New Request: Click the + icon to open a new request tab.
Configure the Request:
- Set the HTTP method dropdown to GET.
- Enter the URL: https://jsonplaceholder.typicode.com/posts/1
Send the Request: Click the blue Send button.

You should immediately see a JSON response in the "Response" section, providing details for a single post:

{
  "userId": 1,
  "id": 1,
  "title": "sunt aut facere repellat provident occaecati excepturi optio reprehenderit",
  "body": "quia et suscipit\nsuscipit recusandae consequuntur expedita et cum\nreprehenderit molestiae ut ut quas totam\nnostrum rerum est est autem sunt rem eveniet architecto"
}

This is a good start, but a response alone isn't proof of correct functionality. This is where API testing comes in!

Real-World Example 1: Robust Response Validation with Tests ✅

The heart of effective API testing in Postman lies in its "Tests" tab. Here, you can write JavaScript code that executes after the API response is received, allowing you to assert conditions and validate data.

Let's add some validation to our previous GET request.

Navigate back to your request tab.
Click on the "Tests" tab (located directly below the URL bar).
Add the following JavaScript code. Postman provides a pm (Postman) object with a powerful API for assertions (pm.expect) and interactions (pm.response, pm.environment, etc.).

// Test 1: Validate the HTTP status code is 200 OK
pm.test("Status code is 200 OK", function () {
    pm.response.to.have.status(200);
});

// Test 2: Ensure the response is of JSON type
pm.test("Content-Type header is application/json", function () {
    pm.response.to.have.header("Content-Type");
    pm.expect(pm.response.headers.get("Content-Type")).to.include("application/json");
});

// Parse the JSON response for further assertions
const responseJson = pm.response.json();

// Test 3: Check if the response body contains the 'title' property
pm.test("Response has 'title' property", function () {
    pm.expect(responseJson).to.have.property('title');
});

// Test 4: Verify the title content for post ID 1
pm.test("Title content is as expected", function () {
    pm.expect(responseJson.title).to.eql("sunt aut facere repellat provident occaecati excepturi optio reprehenderit");
});

// Test 5: Validate the data type of 'userId'
pm.test("userId is a number", function () {
    pm.expect(responseJson.userId).to.be.a('number');
});

// Test 6: Check for a specific value in 'id'
pm.test("ID is 1", function () {
    pm.expect(responseJson.id).to.eql(1);
});

Click "Send" again.
After the response loads, click on the "Test Results" tab in the response section. You should see all your defined tests passing, confirming that the API behaves as expected! 🎉

This example showcases how you can programmatically assert various aspects of an API's response, moving beyond manual inspection to automated, reliable checks.

Real-World Example 2: Chaining Requests with Environment Variables ⛓️

Many real-world API workflows involve sequential operations where the output of one API call serves as the input for a subsequent one. Postman's environment variables are indispensable for managing such dependencies and maintaining dynamic data.

Consider a common scenario:

Create a new resource (e.g., a user, a post) using a POST request.
Retrieve the details of this newly created resource using a GET request, typically by its ID which was returned by the POST request.

Step A: Set up an Environment for Dynamic Data 🛠️

Environments allow you to group related variables and switch between different configurations (e.g., development, staging, production).

In Postman, click the "Environments" dropdown in the top right corner and select "Manage Environments."
Click the "Add" button to create a new environment. Name it DevTo Article Examples.
Add an initial variable:
Variable: baseUrl
Initial Value: https://jsonplaceholder.typicode.com
Current Value: https://jsonplaceholder.typicode.com
Close the "Manage Environments" modal. From the environment dropdown, ensure DevTo Article Examples is selected.

Step B: Create a POST Request to Create a New Resource ✍️

Open a new request tab.
Set the HTTP method to POST.
Set the URL to {{baseUrl}}/posts.

Note: {{baseUrl}} dynamically fetches its value from your selected environment.
Go to the "Body" tab, select the raw radio button, and choose JSON from the dropdown.

Enter the following JSON payload

{
    "title": "My Dynamic Post Created by Postman",
    "body": "This is the body content for a post created dynamically during testing.",
    "userId": 101
}

Navigate to the "Tests" tab and add the following JavaScript. This script will extract the id of the newly created post from the response and store it in an environment variable newPostId.

// Test: Verify the creation status code
pm.test("Status code is 201 Created", function () {
    pm.response.to.have.status(201); // 201 Created is expected for successful resource creation
});

// Extract the 'id' from the response and set it as an environment variable
pm.test("Extract new post ID and set environment variable", function () {
    const responseJson = pm.response.json();
    pm.expect(responseJson).to.have.property('id'); // Ensure the 'id' exists in the response
    pm.environment.set("newPostId", responseJson.id); // Store the ID
    console.log("Newly created Post ID (stored in environment): " + pm.environment.get("newPostId"));
});

Click "Send". You should receive a 201 Created status, and if you click the "eye" icon next to the "Environments" dropdown, you'll see newPostId now holds the ID returned by the API.

Step C: Create a GET Request Using the Extracted ID 🔍

Now, let's use the newPostId to fetch the details of the post we just created.

Open another new request tab.
Set the HTTP method to GET.
Set the URL to {{baseUrl}}/posts/{{newPostId}}.

Note: Both baseUrl and newPostId are dynamically pulled from the environment.
Go to the "Tests" tab and add validation for this GET request:

// Test: Validate the retrieval status code
pm.test("Status code is 200 OK", function () {
    pm.response.to.have.status(200);
});

// Parse the JSON response
const responseJson = pm.response.json();

// Test: Verify the ID of the fetched post matches the stored ID
pm.test("Fetched post ID matches the created ID", function () {
    pm.expect(responseJson.id).to.eql(pm.environment.get("newPostId"));
});

// Test: Verify the title of the fetched post matches the one we sent
pm.test("Fetched post title matches expected", function () {
    pm.expect(responseJson.title).to.eql("My Dynamic Post Created by Postman");
});

Click "Send". You'll observe that the GET request successfully retrieves the specific post created by your previous POST request, demonstrating a powerful chaining mechanism!

This pattern is incredibly valuable for testing complex API workflows like user registration followed by login, or order creation followed by order status updates.

Advanced Strategies for Streamlined Postman Testing 💡

To truly master API testing with Postman, consider integrating these advanced practices into your workflow:

Organize with Collections and Folders: For larger projects, group related requests into Collections and use nested Folders. This improves readability, maintainability, and allows for running subsets of tests.
Pre-request Scripts: Use the "Pre-request Script" tab to execute JavaScript code before a request is sent. This is ideal for generating dynamic data (timestamps, unique IDs), setting up request headers, or handling complex authentication flows (e.g., generating JWTs).
Collection Runner for Automation: Postman's "Collection Runner" allows you to execute an entire collection or a specific folder of requests sequentially. It provides a detailed summary of test results, making it perfect for regression testing. You can also integrate data files (CSV, JSON) for data-driven testing.
Newman for CI/CD Integration: For truly automated testing in your Continuous Integration/Continuous Delivery (CI/CD) pipeline, use Newman. This is Postman's command-line collection runner, enabling you to run your Postman tests as part of your automated build and deployment processes.
Mock Servers: Need to test a front-end application while the backend API is still under development? Postman allows you to set up mock servers that simulate API responses based on your defined examples. This accelerates parallel development.
API Documentation Generation: Postman can automatically generate and host interactive documentation for your APIs directly from your collections, keeping your API specifications always up-to-date.
Environments for Different Stages: Beyond chaining, use environments to manage different API endpoints, credentials, or variable values for various deployment stages (e.g., Development, Staging, Production).~~

Conclusions

Postman is undeniably more than just an API client; it's a comprehensive ecosystem that empowers developers and QA professionals to build, test, document, and monitor APIs with unprecedented efficiency. By embracing its core functionalities – from intuitive request building and powerful test scripting to dynamic environment variables and automated collection runs – you can significantly enhance the quality, reliability, and maintainability of your API-driven applications.

Integrating Postman into your development and testing workflow is a strategic move that pays dividends in the form of fewer bugs, faster release cycles, and a more robust software product. Start exploring its full potential today, and contribute to building the high-quality APIs that power our modern digital world! Happy testing! 🎉

🔐From Zero to SAST Hero: Applying Codacy to a Clean ASP.NET Core Project

GREGORY BRANDON HUANCA MERMA — Thu, 24 Apr 2025 15:54:48 +0000

✅ Introduction

Modern development demands security from the very first line of code.

Static Application Security Testing (SAST) tools help developers detect vulnerabilities early in the development lifecycle.

In this article, I’ll walk you through how to apply Codacy, a powerful but lightweight SAST platform, to an ASP.NET Core MVC project from scratch, including:

✅ Project creation
🧪 Test setup
📊 Code coverage analysis
⚙️ GitHub Actions CI/CD
☁️ Automatic upload to Codacy

🛠️ Step-by-step project setup

🔹 Step 1: Create the base solution and projects

mkdir CodacyDemoApp
cd CodacyDemoApp
dotnet new sln -n CodacyDemo 
dotnet new mvc -n CodacyDemoApp
dotnet new xunit -n CodacyDemoApp.Tests
dotnet sln CodacyDemo.sln add CodacyDemoApp/CodacyDemoApp.csproj
dotnet sln CodacyDemo.sln add CodacyDemoApp.Tests/CodacyDemoApp.Tests.csproj
dotnet add CodacyDemoApp.Tests/CodacyDemoApp.Tests.csproj reference CodacyDemoApp/CodacyDemoApp.csproj

🔹 Step 2: Add a vulnerable class for Codacy to analyze

CodacyDemoApp/Models/User.cs

namespace CodacyDemoApp.Models
{
    public class User
    {
        public string Username { get; set; }
        public string Password { get; set; } // insecure on purpose
    }
}

🔹 Step 3: Create a unit test

CodacyDemoApp.Tests/UnitTest1.cs

using CodacyDemoApp.Models;
using Xunit;

namespace CodacyDemoApp.Tests
{
    public class UserTests
    {
        [Fact]
        public void Should_Create_User_With_Username_And_Password()
        {
            var user = new User { Username = "admin", Password = "123" };
            Assert.Equal("admin", user.Username);
            Assert.Equal("123", user.Password);
        }
    }
}

🔹 Step 4: Run tests and generate coverage

dotnet test CodacyDemoApp.Tests/CodacyDemoApp.Tests.csproj --collect:"XPlat Code Coverage"

🔹 Step 5: Convert coverage to Codacy-compatible format

dotnet tool install --global dotnet-reportgenerator-globaltool
reportgenerator -reports:**/coverage.cobertura.xml -targetdir:coverage-report -reporttypes:Cobertura

🤖 Step 7: Create GitHub Actions workflow

.github/workflows/codacy.yml

name: Codacy Coverage

on:
  push:
    branches: [ main ]
  workflow_dispatch:

jobs:
  analyze:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      - name: Setup .NET
        uses: actions/setup-dotnet@v4
        with:
          dotnet-version: '8.x'

      - name: Restore dependencies
        run: dotnet restore

      - name: Run tests with coverage
        run: dotnet test CodacyDemoApp.Tests/CodacyDemoApp.Tests.csproj --collect:"XPlat Code Coverage"

      - name: Install ReportGenerator
        run: dotnet tool install --global dotnet-reportgenerator-globaltool

      - name: Generate coverage.xml
        run: |
          reportgenerator -reports:**/coverage.cobertura.xml -targetdir:coverage-report -reporttypes:Cobertura

      - name: Upload to Codacy
        shell: bash
        env:
          CODACY_PROJECT_TOKEN: ${{ secrets.CODACY_PROJECT_TOKEN }}
        run: |
          curl -Ls https://coverage.codacy.com/get.sh | bash
          ./codacy-coverage-reporter report -r coverage-report/Cobertura.xml

🔐 Step 8: Configure Codacy

Go to https://app.codacy.com
Import your GitHub repo
Go to Settings > Integrations
Create a new Project API Token
Go back to GitHub > Settings > Secrets > Actions
Add new secret: Name: CODACY_PROJECT_TOKEN Value: (Paste your token)

💻 GitHub Repository

👉 Demo Code + GitHub Actions ready to deploy:

🔗 View on GitHub

This repository includes:

✅ ASP.NET Core MVC project (CodacyDemoApp)
🧪 Unit test project with xUnit (CodacyDemoApp.Tests)
🔍 Static analysis with Codacy
📊 Code coverage reports
⚙️ GitHub Actions workflow:
- .github/workflows/codacy.yml
📄 Detailed setup instructions in README.md

✅ What Codacy detects

Hardcoded passwords

Unused code

Unvalidated input (if added)

Code style issues

Code coverage metric

📊 Example Result

Once set up, Codacy will give you:

Code grade (A–F)

% test coverage

Security, duplication, and style warnings

GitHub PR comments with inline suggestions

🎓 Conclusion

This guide showed how to:

Build a secure, testable .NET app from scratch

Use xUnit for basic unit testing

Generate real code coverage reports

Integrate everything into Codacy and CI/CD

✅ You now have a clean, secure, and automated pipeline for your ASP.NET Core project.

DEV Community: GREGORY BRANDON HUANCA MERMA

API Testing Frameworks Comparison: REST Assured vs Postman vs Playwright

Table of Contents

Overview

REST Assured (Java)

Setup

Basic Test Example

Postman/Newman (JavaScript)

Collection Setup

Pre-request Script

Test Script

Run with Newman

Playwright (TypeScript)

Setup

Test Example

Run Tests

Comparison Table

When to Use Each

Choose REST Assured if:

Choose Postman/Newman if:

Choose Playwright if:

Example Repository Structure

GitHub Actions CI Example

Conclusion

[Boost]

🧪API Testing with Postman: From Basics to Real-World Scenarios 🚀🚀

🧪API Testing with Postman: From Basics to Real-World Scenarios 🚀🚀

Introduction

Why Choose Postman for API Testing? 🤔

Getting Started: Your First API Request and Simple Validation 🏁

Real-World Example 1: Robust Response Validation with Tests ✅

Real-World Example 2: Chaining Requests with Environment Variables ⛓️

Step A: Set up an Environment for Dynamic Data 🛠️

Step B: Create a POST Request to Create a New Resource ✍️

Step C: Create a GET Request Using the Extracted ID 🔍

Advanced Strategies for Streamlined Postman Testing 💡

Conclusions

🔐From Zero to SAST Hero: Applying Codacy to a Clean ASP.NET Core Project

✅ Introduction

🛠️ Step-by-step project setup

🔹 Step 1: Create the base solution and projects

🔹 Step 2: Add a vulnerable class for Codacy to analyze

🔹 Step 3: Create a unit test

🔹 Step 4: Run tests and generate coverage

🔹 Step 5: Convert coverage to Codacy-compatible format

🤖 Step 7: Create GitHub Actions workflow

🔐 Step 8: Configure Codacy

💻 GitHub Repository

✅ What Codacy detects

📊 Example Result

🎓 Conclusion