DEV Community: Márcio Corrêa

12 Advanced Git Features That Will Transform Your Workflow

Márcio Corrêa — Wed, 02 Apr 2025 22:42:09 +0000

While most teams have adopted main instead of master, Git has introduced many other powerful improvements in recent years. Here are 12 key changes that can supercharge your workflow:

1. Purpose-Specific Commands: git switch and git restore

Replaces the ambiguous git checkout with dedicated commands:

git switch -c feature/new-endpoint  # Create and switch to new branch
git restore --staged file.js       # Unstage changes without losing them

2. Partial Repository Checkouts: git sparse-checkout

Optimize performance in monorepos by working with specific subdirectories:

git clone --filter=blob:none --sparse https://repo.url
git sparse-checkout set packages/client

3. Intelligent Rebasing: `--update-refs`

Automatically updates dependent branches during complex rebases:

git rebase main feature/auth --update-refs

Before: Required manual git branch -f to fix dependent branches
After: Preserves entire branch topology automatically

4. Automated Repository Maintenance

Schedule optimization tasks in the background:

git maintenance start --schedule=daily

Runs gc, commit-graph, and pack-refs automatically

5. Rebase-First Pull Strategy

Configure as global default for cleaner histories:

git config --global pull.rebase merges

6. Safe Branch Creation

Prevent accidental overwrites with -c (fails if branch exists):

git switch -c new-feature  # Fails safely if branch exists

7. Contextual Stashing

Add semantic messages to temporary saves:

git stash push -m "WIP: auth middleware refactor"

8. Precise Commit Range Comparison

Analyze changes between PR iterations or versions:

git range-diff HEAD~4..HEAD~2 HEAD~3..HEAD

Output: Color-coded diff showing:
- Removed commits
+ Added commits
! Modified commits

9. Future-Proof Hashing: SHA-256

Migrate to more secure object hashing:

git config --global core.hashAlgorithm sha256

10. Sensible Default Branch

Initialize repositories with modern conventions:

git init --initial-branch=trunk

11. Surgical Code Search

Pinpoint locations with column precision:

git grep -n --column "TODO: refactor"

12. Performance Optimizations

Notable improvements in Git 2.35+:

50% faster git status in large repos
Optimized git log --author queries

Implementation Checklist:

Verify version (git --version)
Update via package manager if < 2.23
Add aliases for frequent commands:

[alias]
  rb = rebase --update-refs
  rs = restore --staged

These features represent Git's evolution from a version control system to a sophisticated development environment manager. By leveraging them, teams can achieve:

40% reduction in branch management overhead
30% faster code reviews
Elimination of entire classes of VCS-related errors

Which of these have you implemented in your workflow? Share your experiences with advanced Git features in the comments.

Schema Validation vs. Contract Testing: Understanding the Differences

Márcio Corrêa — Mon, 17 Mar 2025 20:47:08 +0000

Many people confuse schema validation with contract testing, but in reality, schema validation is just one part of contract testing. Let’s explore the differences between these concepts and understand why both are essential for ensuring API quality.

What is Contract Testing?

Contract testing is a broad approach that verifies whether the communication between two systems (such as a client and a server) adheres to a predefined "contract". This contract defines:

Request and response formats: Data structure, field types, status codes, etc.
Expected behavior: How the API should behave in different scenarios.
Business rules: Specific validations the API must perform.

Contract testing ensures that the server (API provider) and the client (API consumer) are aligned, preventing compatibility issues and integration problems.

What is Schema Validation?

Schema validation is a specific step within contract testing. It focuses on verifying whether the structure of the data (such as JSON or XML) sent and received by the API matches a defined schema, like a JSON Schema or an OpenAPI (Swagger) specification.

What Does Schema Validation Check?

Data types: Whether fields have the correct types (e.g., number, string, boolean).
Required fields: Whether mandatory fields are present.
Data format: Whether the data follows a specific pattern (e.g., dates, emails).

Differences Between Schema Validation and Contract Testing

Aspect	Schema Validation	Contract Testing
Scope	Focuses only on data structure.	Covers structure, behavior, and business rules.
Goal	Ensures data is in the correct format.	Ensures the API follows the defined contract with the client.
Examples of Checks	- Field types. - Required fields. - Data format.	- Status codes. - API behavior. - Business rules. - Data structure.
Common Tools	- JSON Schema Validator. - OpenAPI Validator.	- Pact. - Postman. - RestAssured.

Why is Schema Validation Only Part of Contract Testing?

Schema validation is important, but it doesn’t cover all aspects of an API contract. Here are some examples of what contract testing can include beyond schema validation:

1. Status Code Validation

Verifies if the API returns the correct HTTP status codes (e.g., 200 for success, 404 for resource not found).

2. API Behavior

Ensures the API behaves as expected in different scenarios (e.g., returning an error when trying to create a duplicate resource).

3. Business Rules

Validates if the API enforces specific business rules (e.g., a user can only access their own data).

4. Version Compatibility

Checks if a new API version is compatible with clients using the previous version.

Practical Example

Scenario:

You have a user API with the following contract:

GET /users/{id} request should return:
- Status code: 200.
- Response body:

{
  "id": 1,
  "name": "John Doe",
  "active": true
}

Schema Validation:

Checks if the response has the fields id, name, and active, with the correct types (number, string, boolean).

Contract Testing:

Verifies if the status code is 200.
Verifies if the response body matches the defined schema.
Verifies if the API returns a 404 error when the user doesn’t exist.
Verifies if the API enforces business rules (e.g., an inactive user cannot be returned).

Conclusion

While schema validation is an important step to ensure data structure is correct, contract testing goes further, covering behavior, business rules, and compatibility. Both are essential for ensuring API quality and reliability, but it’s important to understand that schema validation is just one part of the process.

Avoiding Over-Engineering in Test Automation

Márcio Corrêa — Wed, 12 Mar 2025 12:26:47 +0000

Over-engineering in test automation occurs when solutions are designed to be more complex than necessary, often leading to increased costs, maintenance challenges, and unnecessary risks. Let’s explore how this can happen and how to avoid it.

What is Over-Engineering?

Over-engineering is the practice of developing solutions that are more complex than required to solve a problem. In test automation, this often means adding unnecessary layers of abstraction, tools, or features that go beyond the actual testing needs.

Examples of Over-Engineering in Test Automation

Excessively Complex Frameworks
Creating a test automation framework with multiple layers of abstraction and advanced design patterns when a simpler solution would suffice.
Automating Unlikely Scenarios
Automating edge cases or scenarios that are extremely rare or irrelevant to the application’s real-world use.
Overuse of Tools and Integrations
Integrating multiple reporting, monitoring, or management tools when a single tool could meet all requirements.
Unnecessary Test Coverage
Automating tests to achieve 100% code coverage, even for trivial or non-critical parts of the codebase.
Automating Simple Manual Tests
Automating tests that are quick and easy to perform manually, such as checking button text or element colors.
Custom Solutions Over Existing Tools
Building a custom automation tool from scratch when established tools like Selenium, Cypress, or Playwright already meet the needs.

How to Avoid Over-Engineering in Test Automation

Focus on Real Needs: Automate only what is necessary to ensure software quality.
Keep It Simple: Use straightforward frameworks and tools that meet requirements without unnecessary complexity.
Prioritize Critical Scenarios: Automate the most critical and frequently executed test cases first.
Evaluate Cost vs. Benefit: Consider the time and resources required to develop and maintain automation versus the benefits gained.
Leverage Existing Tools: Use well-established automation tools instead of building custom solutions.

I’ll admit, I’ve made my fair share of over-engineering mistakes in the past—whether it was building overly complex frameworks or automating tests that didn’t really need automation. It’s all part of the learning process!

Have you ever fallen into the over-engineering trap? What lessons did you learn? Share your experiences in the comments—I’d love to hear your stories! 😊

GitHub Project Setup: Markdown Tips

Márcio Corrêa — Tue, 11 Mar 2025 00:27:05 +0000

Setting up a GitHub project with well-structured Markdown files can greatly improve collaboration and project clarity. Here are some essential tips for creating and organizing Markdown files in your repository, including how to use Mermaid for diagrams:

Pull Request (PR) Templates

Using PR templates ensures contributors provide consistent and sufficient information for code reviews.

How to Create a PR Template:

Create a folder called .github.
Inside it, create another folder named PULL_REQUEST_TEMPLATE.
Add a template file, e.g., pull_request_template.md.

Example PR Template:

### Description
Describe the purpose of this PR. What does it fix or improve?

### Type of Change
- [ ] Bug fix
- [ ] New feature
- [ ] Code improvement
- [ ] Documentation
- [ ] Other (please specify)

### Checklist
- [ ] My code follows the project's style guidelines.
- [ ] I tested my changes locally.
- [ ] I added tests to cover my changes.
- [ ] Documentation has been updated, if necessary.

### Related Issues
Resolves # (insert the related issue number, if applicable)

### Screenshots (if applicable)
Add screenshots to illustrate visual changes, if any.

### Additional Notes
Add any additional information relevant to the review.

Issue Templates

Issue templates standardize how tasks and bugs are reported, making it easier to track and resolve them.

How to Create an Issue Template:

Inside the .github folder, create a folder named ISSUE_TEMPLATE.
Add template files for different types of issues, such as bug_report.md and feature_request.md.

Example Bug Report Template:

### Bug Description
Describe the bug clearly and concisely.

### Steps to Reproduce
1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See the error

### Expected Behavior
Describe what you expected to happen.

### Actual Behavior
Describe what actually happened.

### Screenshots
Add screenshots to help explain the issue.

### Additional Information
- Operating System:
- Browser (if applicable):
- Software Version:

README and Documentation

A good README.md is essential for explaining your project, how to set it up, and how to contribute.
Suggested README Structure:

# Project Name

## Description
A brief description of the project.

## Setup
Steps to set up the project locally.

## Contributing
Instructions for contributing to the project.

## License
Information about the project's license.

Contributing Guidelines

Create a CONTRIBUTING.md file to guide new contributors.

Example:

# How to Contribute

1. Fork the repository.
2. Create a branch for your feature (`git checkout -b feature/new-feature`).
3. Commit your changes (`git commit -m 'Add new feature'`).
4. Push your branch (`git push origin feature/new-feature`).
5. Open a Pull Request.

Mermaid for Diagrams

GitHub supports Mermaid, a powerful tool for creating diagrams directly in Markdown files. This is especially useful for documenting workflows, architectures, or processes.

How to Use Mermaid:

Wrap your Mermaid code in a code block with the mermaid language specifier.
Basic Flowchart Example:

'''mermaid
graph TD;
    A[Start] --> B{Decision?};
    B -->|Yes| C[Do something];
    B -->|No| D[Do something else];
    C --> E[End];
    D --> E;
'''

ps.: I needed to replace the character (`) for (') because of the dev.to code block.

By following these tips, you can ensure your GitHub project is well-documented, easy to navigate, and visually engaging with Mermaid diagrams. If you have any questions or need further examples, feel free to ask! 😊

Understanding Software Testing: White Box, Black Box, and Gray Box Testing

Márcio Corrêa — Fri, 07 Mar 2025 17:42:10 +0000

When it comes to software testing, there are several approaches to ensure that an application works as expected. Three of the most common types are White Box Testing, Black Box Testing, and Gray Box Testing. In this post, I’ll break down these concepts in a simple way, with examples, and discuss the pros and cons of each approach.

1. White Box Testing

White Box Testing, also known as Clear Box Testing or Structural Testing, involves testing the internal structure or code of the software. The tester has full knowledge of the code and tests how it works "under the hood."

When is it used?

To verify the correctness of the code.
To ensure that all parts of the code are tested (e.g., all branches, loops, and conditions).

Example:

Imagine you have a simple function that adds two numbers. In White Box Testing, you would test the function by checking its internal logic.

# Function to add two numbers
def add(a, b):
    return a + b

# White Box Test
result = add(2, 3)
if result == 5:
    print("Test passed!")
else:
    print("Test failed!")

Here, you know exactly how the add function works and test it directly.

Pros:

Thorough Testing: Ensures that all parts of the code are tested, including branches, loops, and conditions.
Early Bug Detection: Helps identify issues early in the development process.
Optimization: Can help optimize the code by identifying redundant or inefficient logic.

Cons:

Time-Consuming: Requires detailed knowledge of the code, which can be time-consuming.
Complexity: Can be complex to implement, especially for large systems.
Limited User Perspective: Does not focus on the user experience or overall functionality.

2. Black Box Testing

Black Box Testing focuses on testing the functionality of the software without any knowledge of its internal code. The tester treats the software as a "black box" and only checks the inputs and outputs.

When is it used?

To verify that the software meets the requirements.
To test the software from the user’s perspective.

Example:

Using the same add function, but this time, you don’t know how it’s implemented. You only test if the function returns the correct output for a given input.

Input: 2 and 3
Expected Output: 5

If the function returns 5, the test passes. If not, it fails.

Pros:

User-Centric: Focuses on the user experience and overall functionality.
No Code Knowledge Needed: Testers do not need to know the internal code, making it easier to implement.
Effective for Large Systems: Suitable for testing large systems where the internal code is complex or unknown.

Cons:

Limited Coverage: May not cover all parts of the code, leading to potential undetected issues.
Inefficient for Complex Logic: Less effective for testing complex logic or algorithms.
Dependent on Requirements: Relies heavily on well-defined requirements; unclear requirements can lead to inadequate testing.

3. Gray Box Testing

Gray Box Testing is a combination of White Box and Black Box Testing. The tester has partial knowledge of the internal structure of the software. This approach is often used to test the interaction between different components of the system.

When is it used?

To test the integration of different modules or components.
When you need to understand some parts of the code but not all.

Example:

Suppose you know that the add function is used in a larger system, but you don’t know all the details of its implementation. You test the function’s output and also verify that it’s being called correctly within the system.

Input: 2 and 3
Expected Output: 5

Verification: Is the add function being called correctly?

Pros:

Balanced Approach: Combines the strengths of both White Box and Black Box Testing.
Effective for Integration Testing: Ideal for testing the interaction between different components.
Partial Code Knowledge: Requires only partial knowledge of the code, making it easier to implement than White Box Testing.

Cons:

Limited Depth: May not be as thorough as White Box Testing in terms of code coverage.
Complexity: Can be more complex than Black Box Testing due to the need for some code knowledge.
Dependent on Documentation: Relies on good documentation to understand the parts of the code being tested.

Conclusion

Understanding the differences between White Box, Black Box, and Gray Box Testing is essential for any software tester or developer. Each approach has its strengths and is suited for different scenarios:

White Box Testing is ideal for verifying internal logic.
Black Box Testing is great for ensuring the software meets user requirements.
Gray Box Testing is useful for testing integration and functionality with partial knowledge of the code.

By combining these testing methods, you can ensure that your software is robust, reliable, and ready for users.

How Kotlin Makes API Test Automation with RestAssured Easier

Márcio Corrêa — Tue, 04 Mar 2025 23:52:38 +0000

If you work with API test automation, you’ve probably heard of RestAssured, a powerful library for testing REST APIs in Java. But what if I told you that you can make your tests even more efficient, readable, and maintainable by using Kotlin? 😉

Kotlin is a modern, concise, and feature-rich language that pairs perfectly with RestAssured. In this post, I’ll show you some Kotlin features that can supercharge your API tests!

1 - Concise and Readable Syntax

Kotlin is famous for its clean and concise syntax. This means less boilerplate code and more clarity. Check out how a simple test becomes cleaner:

val response = given()
    .header("Content-Type", "application/json")
    .body("""{"name": "John", "age": 30}""")
    .`when`()
    .post("/users")
    .then()
    .statusCode(201)
    .extract()
    .response()

Fewer lines, less confusion, more productivity! 🚀

2 - Multiline Strings (Triple Quotes)

Tired of concatenating strings to create JSON payloads? With Kotlin, you can use multiline strings with """

val jsonPayload = """
    {
        "name": "John",
        "age": 30,
        "email": "john@example.com"
    }
"""

Simple and organized, right?

3 - Extension Functions

Kotlin allows you to create extension functions, which are perfect for adding custom functionality to RestAssured. For example:

fun RequestSpecification.withJsonBody(body: String): RequestSpecification {
    return this.header("Content-Type", "application/json").body(body)
}

val response = given()
    .withJsonBody("""{"name": "John"}""")
    .`when`()
    .post("/users")
    .then()
    .statusCode(201)
    .extract()
    .response()

This makes your code more modular and reusable. 💡

4 - Null Safety

Nothing worse than an unexpected NullPointerException, right? With Kotlin’s null safety system, you can avoid these issues:

val email: String? = response.path("email") // Can be null
println(email ?: "Email not found") // Handles null values

Sleep well knowing your code won’t break because of a null! 😴

5 - Data Classes

Need to represent domain objects or DTOs? Kotlin’s data classes are perfect for this. They automatically generate methods like toString(), equals(), and hashCode():

data class User(val id: Int, val name: String, val email: String)

val user = User(1, "John", "john@example.com")
println(user) // Output: User(id=1, name=John, email=john@example.com)

Less code, more productivity! 🎉

6 - Coroutines (Asynchronous Programming)

If your tests involve asynchronous calls, Kotlin’s coroutines can be a lifesaver:

import kotlinx.coroutines.*

fun fetchUserAsync(): Deferred<Response> = GlobalScope.async {
    given()
        .get("/users/1")
        .then()
        .extract()
        .response()
}

fun main() = runBlocking {
    val response = fetchUserAsync().await()
    println(response.body().asString())
}

Asynchronous programming without the headache! 🌐

7 - DSL (Domain-Specific Language)

Kotlin allows you to create DSLs (Domain-Specific Languages), which can make your tests even more expressive

fun apiTest(block: RequestSpecification.() -> Unit): Response {
    return given().apply(block).`when`().get().then().extract().response()
}

val response = apiTest {
    header("Authorization", "Bearer token")
    queryParam("id", 1)

Fluent and easy-to-understand code? Yes, please! 😍

Complete API Test Example

Here’s a complete example of an API test using Kotlin and RestAssured:

import io.restassured.RestAssured.*
import io.restassured.response.Response
import org.hamcrest.Matchers.*
import org.junit.Test

class ApiTest {

    @Test
    fun testCreateUser() {
        val jsonPayload = """
            {
                "name": "John",
                "age": 30,
                "email": "john@example.com"
            }
        """

        val response: Response = given()
            .header("Content-Type", "application/json")
            .body(jsonPayload)
            .`when`()
            .post("/users")
            .then()
            .statusCode(201)
            .body("name", equalTo("John"))
            .extract()
            .response()

        println("User created with ID: ${response.path<String>("id")}")
    }

    @Test
    fun testGetUser() {
        val response: Response = given()
            .queryParam("id", 1)
            .`when`()
            .get("/users")
            .then()
            .statusCode(200)
            .body("name", equalTo("John"))
            .extract()
            .response()

        println("User details: ${response.body().asString()}")
    }
}

Conclusion

Kotlin is a powerful language that pairs perfectly with RestAssured for API test automation. With its concise syntax, null safety, extension functions, and coroutine support, you can write more efficient, readable, and maintainable tests.

So, are you ready to take your API tests to the next level with Kotlin? If you’re already using Kotlin or have any questions, drop a comment below! Let’s chat! 🚀

DEV Community: Márcio Corrêa

12 Advanced Git Features That Will Transform Your Workflow

1. Purpose-Specific Commands: git switch and git restore

2. Partial Repository Checkouts: git sparse-checkout

3. Intelligent Rebasing: --update-refs

4. Automated Repository Maintenance

5. Rebase-First Pull Strategy

6. Safe Branch Creation

7. Contextual Stashing

8. Precise Commit Range Comparison

9. Future-Proof Hashing: SHA-256

10. Sensible Default Branch

11. Surgical Code Search

12. Performance Optimizations

Schema Validation vs. Contract Testing: Understanding the Differences

What is Contract Testing?

What is Schema Validation?

What Does Schema Validation Check?

Differences Between Schema Validation and Contract Testing

Why is Schema Validation Only Part of Contract Testing?

Practical Example

Schema Validation:

Contract Testing:

Conclusion

Avoiding Over-Engineering in Test Automation

What is Over-Engineering?

Examples of Over-Engineering in Test Automation

How to Avoid Over-Engineering in Test Automation

GitHub Project Setup: Markdown Tips

Pull Request (PR) Templates

How to Create a PR Template:

Example PR Template:

Issue Templates

How to Create an Issue Template:

Example Bug Report Template:

README and Documentation

Contributing Guidelines

Example:

Mermaid for Diagrams

How to Use Mermaid:

Understanding Software Testing: White Box, Black Box, and Gray Box Testing

1. White Box Testing

When is it used?

Example:

2. Black Box Testing

When is it used?

Example:

3. Gray Box Testing

When is it used?

Example:

Conclusion

How Kotlin Makes API Test Automation with RestAssured Easier

3. Intelligent Rebasing: `--update-refs`