DEV Community: Renzo Fernando LOYOLA VILCA CHOQUE

Decoupling Domain from Persistence: Implementing the Repository Pattern in Python

Renzo Fernando LOYOLA VILCA CHOQUE — Wed, 24 Jun 2026 21:51:51 +0000

Introduction and Context
In enterprise applications, one of the most common anti-patterns is mixing business rules (Domain Logic) with database queries (Persistence Logic). As your application grows, this practice leads to highly coupled, fragile, and hard-to-test code.

In his seminal book Patterns of Enterprise Application Architecture (PofEAA), Martin Fowler defines the Repository pattern as a mediator between the domain and data mapping layers, acting like an in-memory collection of domain objects.

How Does the Repository Pattern Work?
Instead of writing SQL queries or direct ORM calls inside your business services, you interact with an abstraction (an interface). The domain layer doesn’t know—and shouldn't care—whether the data comes from a PostgreSQL database, a local JSON file, or an external API. It simply requests or provides domain objects.

Real-World Case Study: Academic Tutoring Management System
Imagine we are building the backend for a university tutoring platform. We need to manage tutoring sessions without coupling our core business logic to a specific database engine.

The Domain Entity (Pure Business Logic) This class represents our core business domain. It is completely decoupled from any frameworks or database libraries.

Python

domain.py

from datetime import datetime
from dataclasses import dataclass

@dataclass
class TutoringSession:
id: str
student_id: str
tutor_id: str
date_time: datetime
subject: str
is_active: bool = True

def cancel_session(self):
    if self.date_time < datetime.now():
        raise ValueError("Cannot cancel a session that has already occurred.")
    self.is_active = False

The Repository Interface (Abstraction) We define the contract that any concrete persistence mechanism must implement.

Python

repository_interface.py

from abc import ABC, abstractmethod
from typing import List, Optional
from domain import TutoringSession

class ITutoringRepository(ABC):

@abstractmethod
def save(self, session: TutoringSession) -> None:
    """Saves or updates a tutoring session."""
    pass

@abstractmethod
def find_by_id(self, session_id: str) -> Optional[TutoringSession]:
    """Retrieves a session by its unique identifier."""
    pass

@abstractmethod
def find_active_by_tutor(self, tutor_id: str) -> List[TutoringSession]:
    """Retrieves all active tutoring sessions for a specific tutor."""
    pass

The Concrete Implementation (In-Memory for Infrastructure/Testing) While you would use SQLAlchemy or a database client for production, the pattern allows us to create an in-memory version instantaneously for blazing-fast software testing.

Python

in_memory_repository.py

from typing import List, Optional, Dict
from domain import TutoringSession
from repository_interface import ITutoringRepository

class InMemoryTutoringRepository(ITutoringRepository):
def init(self):
self._db: Dict[str, TutoringSession] = {}

def save(self, session: TutoringSession) -> None:
    self._db[session.id] = session

def find_by_id(self, session_id: str) -> Optional[TutoringSession]:
    return self._db.get(session_id)

def find_active_by_tutor(self, tutor_id: str) -> List[TutoringSession]:
    return [
        session for session in self._db.values()
        if session.tutor_id == tutor_id and session.is_active
    ]

The Service Layer (Use Case Execution) Notice how the service consumes the repository interface without knowing how or where the data is actually stored.

Python

service.py

from domain import TutoringSession
from repository_interface import ITutoringRepository

class TutoringService:
def init(self, repository: ITutoringRepository):
self.repository = repository

def schedule_new_session(self, session: TutoringSession) -> None:
    # Complementary business logic validation
    current_sessions = self.repository.find_active_by_tutor(session.tutor_id)
    if len(current_sessions) >= 5:
        raise Exception("The tutor has already reached the maximum limit of active sessions.")

    self.repository.save(session)

Key Takeaways and Benefits
Absolute Testability: You can unit test your TutoringService by passing the InMemoryTutoringRepository in milliseconds, without needing to spin up Docker containers or real databases.

Substitutability: If you ever decide to migrate from a relational SQL database to a NoSQL engine or Firebase, your core business layer (service.py and domain.py) remains completely untouched. You simply write a new repository class that implements ITutoringRepository.

🛠️ GitHub Repository Guide
To make your repository look highly professional to your professor and research group, structure your project cleanly like this:

Plaintext
enterprise-patterns-repository/
│
├── src/
│ ├── init.py
│ ├── domain.py
│ ├── repository_interface.py
│ ├── in_memory_repository.py
│ └── service.py
│
├── main.py # A small executable script demonstrating the workflow
├── README.md # Clear documentation on how to run the code
└── .gitignore
Inside your main.py, place a simple execution flow to showcase your pattern in action:

Python
from datetime import datetime
from src.domain import TutoringSession
from src.in_memory_repository import InMemoryTutoringRepository
from src.service import TutoringService

if name == "main":
# Initialize infrastructure and service layers
repo = InMemoryTutoringRepository()
service = TutoringService(repo)

# Create a domain object
new_session = TutoringSession(
    id="SES-001", 
    student_id="STUDENT-10", 
    tutor_id="TUTOR-05", 
    date_time=datetime(2026, 7, 1, 15, 0), 
    subject="Software Architecture Patterns"
)

# Execute the business use case
service.schedule_new_session(new_session)
print(f"Session {new_session.id} successfully saved to the Repository.")

Mastering Design Principles: Dependency Inversion in Kotlin

Renzo Fernando LOYOLA VILCA CHOQUE — Wed, 17 Jun 2026 23:35:24 +0000

Abstract

In modern software engineering, writing code that simply "works" is only the first step. The real challenge lies in designing systems that are maintainable, scalable, and easy to test. This article explores the Dependency Inversion Principle (DIP), the final pillar of the SOLID design principles. Through a practical, real-world example in Kotlin, we will demonstrate how to transition from a tightly coupled architecture to an abstraction-based design. This shift dramatically improves our codebase, facilitates unit testing, and prepares our applications for future growth.

Introduction: The Chaos of Coupling

As applications grow, it is common to see how a minor change in a database schema or a third-party API triggers a domino effect, breaking unrelated parts of the system. This fragility is a direct consequence of tight coupling.

Software design principles, particularly SOLID, were established to prevent this architectural decay. Today, we focus on the "D" in SOLID: the Dependency Inversion Principle (DIP). This principle establishes two core rules:

High-level modules should not depend on low-level modules. Both should depend on abstractions (interfaces).

Abstractions should not depend on details. Details (concrete implementations) should depend on abstractions.

The Scenario: An E-commerce Payment Processor

Imagine you are building the billing system for an online store. To process purchases, the system needs to connect to a payment gateway, such as PayPal.

The Bad Way: Tight Coupling (Violating DIP)

In this initial design, our high-level business logic (OrderProcessor) directly instantiates and depends on the concrete low-level class (PayPalService).

// Low-level component (Concrete detail)
class PayPalService {
fun executePayment(amount: Double) {
println("Processing payment of $$amount via PayPal API.")
}
}

// High-level component (Business logic)
class OrderProcessor {
// Tight coupling: this class depends directly on a concrete implementation
private val payPalService = PayPalService()

fun completeOrder(orderId: String, total: Double) {
    println("Initiating processing for order: $orderId")
    payPalService.executePayment(total)
}

}

fun main() {
val processor = OrderProcessor()
processor.completeOrder("ORD-101", 89.90)
}

Why is this design fragile?

Zero Testability: You cannot easily test OrderProcessor in isolation. Any unit test will attempt to make an actual API call to PayPalService, resulting in slow, brittle tests that depend on network connectivity.

Rigidity: If the business team decides to switch the payment provider from PayPal to Stripe tomorrow, you will have to manually modify the internal code of OrderProcessor. This also violates the Open/Closed Principle (OCP).

The Better Way: Introducing Abstraction (Applying DIP)

To resolve this, we invert the dependency. We introduce an interface that acts as a contract between the high-level business logic and the low-level implementation details. Both components will now depend on this abstraction.

// 1. Define the Abstraction (The contract)
interface PaymentGateway {
fun processPayment(amount: Double)
}

// 2. Concrete Implementation for PayPal
class PayPalProvider : PaymentGateway {
override fun processPayment(amount: Double) {
println("Payment of $$amount processed securely via PayPal.")
}
}

// 3. Concrete Implementation for Stripe (Easy to add later!)
class StripeProvider : PaymentGateway {
override fun processPayment(amount: Double) {
println("Payment of $$amount processed securely via Stripe.")
}
}

// 4. High-level component depending ONLY on the interface
// We use Dependency Injection via the constructor
class OrderProcessor(private val paymentGateway: PaymentGateway) {

fun completeOrder(orderId: String, total: Double) {
    println("Initiating processing for order: $orderId")
    paymentGateway.processPayment(total)
}

}

fun main() {
// We instantiate the providers independently
val payPal = PayPalProvider()
val stripe = StripeProvider()

// Now we inject whichever dependency we need at runtime
println("--- Using PayPal ---")
val orderProcessorWithPayPal = OrderProcessor(payPal)
orderProcessorWithPayPal.completeOrder("ORD-202", 45.00)

println("\n--- Using Stripe ---")
val orderProcessorWithStripe = OrderProcessor(stripe)
orderProcessorWithStripe.completeOrder("ORD-203", 120.50)

}

Conclusion

By applying the Dependency Inversion Principle, we transformed a rigid, high-maintenance codebase into a highly modular, decoupled system.

Key Benefits:

Maintainability: Adding a new payment gateway (e.g., Apple Pay or Google Pay) does not require changing a single line of code in the OrderProcessor. We simply create a new class implementing the PaymentGateway interface.

Excellent Testability: In a unit testing environment, you can pass a mocked implementation of PaymentGateway to OrderProcessor, verifying its business logic without invoking real network requests or external APIs.

Investing time in establishing clean boundaries between components pays off immensely as your codebase scales. Clean code is happy code!

Draft Article: Mastering Software Design Principles

Renzo Fernando LOYOLA VILCA CHOQUE — Wed, 17 Jun 2026 23:25:47 +0000

Beyond Spaghetti Code: Embracing the Dependency Inversion Principle in Kotlin
Abstract
In modern software engineering, writing code that "just works" is no longer enough. The real challenge lies in designing systems that are maintainable, scalable, and resilient to change. This article explores the core concepts of Software Design Principles, focusing on the Dependency Inversion Principle (DIP) from SOLID. Through a practical, real-world example in Kotlin, we will demonstrate how moving from tightly coupled implementations to clean abstractions can dramatically improve your codebase's testability and flexibility.

Introduction: Why Design Principles Matter
As applications grow, codebases tend to become rigid. A simple change in a database structure or a third-party API can trigger a domino effect of bugs across the entire system. This is where software design principles come to the rescue.

By adhering to established architectural patterns and principles (such as SOLID, DRY, and KISS), developers can decouple components. This ensures that modules can be modified, replaced, or tested independently without breaking the surrounding infrastructure.

The Real-World Scenario: A Payment Gateway Integration
Imagine you are building an e-commerce application. One of the core requirements is processing payments. A naive approach often results in a high-level module (like an order processor) directly depending on a low-level concrete implementation (like a specific payment provider's SDK).

The Bad Way: Tight Coupling (Violating DIP)
In the code snippet below, our OrderProcessor is completely tied to a specific PayPalService. If marketing decides to switch to Stripe tomorrow, or if we want to run unit tests without hitting the real live API, we are in deep trouble.

// Low-level concrete component
class PayPalService {
fun executePayment(amount: Double) {
println("Processing payment of $$amount via PayPal API.")
}
}

// High-level component directly depending on a concrete class
class OrderProcessor {
private val payPalService = PayPalService() // Tight coupling!

fun completeOrder(orderId: String, total: Double) {
    println("Completing order: $orderId")
    payPalService.executePayment(total)
}

}

fun main() {
val processor = OrderProcessor()
processor.completeOrder("ORD-1001", 79.99)
}

Why this is fragile:

Zero Testability: You cannot easily mock PayPalService to test OrderProcessor logic in isolation.

Rigidity: Changing the payment provider requires rewrites inside OrderProcessor.

The Better Way: Introducing Abstraction (Applying DIP)
To fix this, the Dependency Inversion Principle dictates that high-level modules should not depend on low-level modules; both should depend on abstractions.

Let's refactor the code by introducing a PaymentService interface.

// The Abstraction layer
interface PaymentService {
fun processPayment(amount: Double)
}

// Low-level concrete implementation 1
class PayPalProvider : PaymentService {
override fun processPayment(amount: Double) {
println("Securely processing $$amount via PayPal.")
}
}

// Low-level concrete implementation 2 (Easy to add later!)
class StripeProvider : PaymentService {
override fun processPayment(amount: Double) {
println("Securely processing $$amount via Stripe.")
}
}

// High-level component depending ONLY on the interface
class OrderProcessor(private val paymentService: PaymentService) { // Dependency Injection

fun completeOrder(orderId: String, total: Double) {
    println("Completing order: $orderId")
    paymentService.processPayment(total)
}

}

fun main() {
// We can swap the provider effortlessly via construction
val payPalProvider = PayPalProvider()
val stripeProvider = StripeProvider()

val orderProcessorWithPayPal = OrderProcessor(payPalProvider)
orderProcessorWithPayPal.completeOrder("ORD-2002", 45.50)

val orderProcessorWithStripe = OrderProcessor(stripeProvider)
orderProcessorWithStripe.completeOrder("ORD-2003", 120.00)

}

Conclusion
By inverting dependencies using Kotlin's clean interface and constructor injection capabilities, we transformed a rigid, untestable class into a highly adaptable component. Now, adding new payment providers or injecting fake mock instances for unit testing requires zero changes to the underlying business logic of OrderProcessor.

Investing time in robust software design principles early in development saves countless hours of refactoring down the road. Happy coding!

Secure Your Python App Using Bandit as a SAST Tool

Renzo Fernando LOYOLA VILCA CHOQUE — Sat, 06 Dec 2025 01:18:08 +0000

Static Application Security Testing (SAST) tools help you detect vulnerabilities directly in your source code before the application is executed or deployed. In this article, you will see how to use Bandit, a Python‑focused SAST tool, to scan a Python application and improve its security posture.

What Is SAST and Why It Matters
SAST refers to techniques and tools that analyze source code, bytecode or binaries to find security weaknesses without running the application. These tools search for patterns related to insecure practices such as injection, unsafe system calls, weak cryptography, or hardcoded secrets.

Running SAST early in the development lifecycle allows teams to detect and fix issues before they reach production, which reduces both risk and remediation cost. Integrating SAST into everyday workflows (IDE checks, pre‑commit hooks or CI/CD pipelines) transforms security from a late, manual step into a continuous, automated practice.

Meet Bandit: A Python Security Linter
Bandit is an open source security linter designed to find common security issues in Python code. It parses Python files, builds an abstract syntax tree (AST), and runs a set of security tests to detect problems such as hardcoded passwords, use of unsafe functions like exec, insecure random generators, weak hashes, or risky XML and subprocess usage.

Because Bandit understands Python syntax and idioms, it can provide more precise findings than generic text‑based scanners for this language. It is distributed through PyPI, actively maintained by the PyCQA community, and can be easily integrated into local development workflows and CI/CD pipelines.

Setting Up Bandit in Your Project
To use Bandit, you only need a working Python environment and pip. Many developers prefer to create a virtual environment so that security tools and project dependencies do not conflict.

Example setup steps (run in your terminal):

Create and activate a virtual environment (optional).

Install Bandit with pip: pip install bandit.

Optionally, install extra features like TOML support, baseline management or SARIF output using extras such as bandit[toml], bandit[baseline] or bandit[sarif].

After installation, the bandit command becomes available in your shell so you can run it from any project directory.

Scanning a Python Application with Bandit
Once Bandit is installed, you can scan either a single file or an entire project directory. The most common workflow is to navigate to the root of your Python project and run Bandit recursively.

Typical examples:

Scan a single file: bandit app.py

Scan a whole project recursively: bandit -r .

When the scan finishes, Bandit prints a report showing each issue it found, along with fields like severity, confidence, file path, line number and a short description. You can also change the output format to JSON, XML, HTML, YAML and others, which is useful for storing results or integrating with dashboards.

Understanding Bandit’s Output
Bandit assigns two key attributes to each finding: severity and confidence. Severity indicates how serious the potential vulnerability is (for example low, medium or high), while confidence reflects how certain Bandit is that the pattern represents a real security problem.

High‑severity, high‑confidence issues typically indicate dangerous patterns such as use of weak cryptographic functions, insecure temporary files, unsafe XML parsers or shell commands with untrusted input. Developers should review these findings in context, confirm whether they are valid issues, and then apply fixes such as input validation, parameterization, replacing weak algorithms or refactoring dangerous code.

Applying Bandit to a Sample Scenario
Imagine a small Python web application that performs file operations, calls external commands and processes user input. Bandit can help identify if:

Temporary files are created using insecure methods.

User input is passed directly into shell commands or SQL queries.

Insecure modules like telnetlib or weak hash functions like md5 are in use.

Running bandit -r . from the project root will reveal these patterns with line numbers and explanations, making it easier to refactor the application before deployment.

Integrating Bandit into CI/CD
The real power of a SAST tool appears when it becomes part of your automated pipelines. With Bandit, you can add a CI job that installs dependencies, runs bandit -r ., and fails the pipeline if new high‑severity issues are introduced.

For example, in a GitHub Actions or GitLab CI pipeline, you can:

Use a Python base image, install Bandit and run it as part of your test stage.

Configure Bandit to output JSON or SARIF and upload that report as a pipeline artifact or feed it into security dashboards.

Optionally, use a baseline file to compare current results against previous scans, so only new findings break the build.

This approach ensures every pull request is checked for security issues, not only for functionality or style.

Best Practices When Using Bandit
To get the most value from Bandit, consider these practices:

Run Bandit locally as part of a pre‑commit hook so that insecure patterns are caught before code is pushed.

Adjust severity and confidence thresholds to match your project’s risk tolerance, focusing on high‑impact issues first.

Regularly review and update the configuration (for example .bandit.yml) to skip false positives or define project‑specific rules.

Combine Bandit with other security practices such as dependency scanning, dynamic testing and manual code review.

Bandit is not a silver bullet, but it is a lightweight and effective way to bring security awareness into everyday Python development.

Limitations and Complementary Tools
Bandit focuses on static analysis of Python source code, so it does not replace dynamic application security testing or runtime protection. It may also miss complex logic issues that require deeper understanding of business rules, which is why human review remains essential.

For a more complete security strategy, combine Bandit with tools that check open‑source dependencies, perform dynamic scans against running environments and monitor production systems. Even with these limitations, integrating Bandit as your SAST tool for Python significantly raises your application’s security baseline with relatively low effort

Applying API testing frameworks: real-world code examples

Renzo Fernando LOYOLA VILCA CHOQUE — Sat, 06 Dec 2025 00:53:35 +0000

Applying API testing frameworks: real-world code examples
Modern applications dependen de APIs para conectar frontends, servicios internos y terceros. Validar estas APIs de forma automática es clave para evitar regresiones y detectar errores antes de llegar a producción. En este artículo verás cómo aplicar marcos de prueba de API con ejemplos reales usando Postman (JavaScript) y Rest Assured (Java), y cómo integrarlos en un flujo de CI/CD.

Why API testing matters
API testing permite validar lógica de negocio, contratos y reglas de seguridad sin necesidad de una interfaz gráfica. Cuando se integra en pipelines de CI/CD, ayuda a detectar fallos de manera temprana y a mantener lanzamientos frecuentes pero estables. Además, automatizar estas pruebas reduce el trabajo manual del QA y mejora la confianza en cada despliegue.

Choosing an API testing framework
Existen múltiples herramientas para probar APIs: Postman, Rest Assured, Karate, JMeter, SoapUI, entre otras. Cada una ofrece ventajas según el lenguaje, el tipo de proyecto y el nivel de experiencia del equipo. En este artículo nos centraremos en dos opciones muy usadas en la industria: Postman para flujos rápidos y colaborativos, y Rest Assured para pruebas integradas en suites Java.

Postman: testing with JavaScript
Postman es una herramienta muy popular para diseñar, documentar y probar APIs, tanto de forma manual como automatizada. Permite agrupar peticiones en Collections, usar entornos con variables, y añadir scripts en JavaScript para ejecutar aserciones sobre las respuestas.

Un flujo típico de prueba funcional en Postman incluye:

Definir la petición (método, URL, headers, body).

Añadir scripts en la pestaña “Tests” para validar el resultado.

Ejecutar la Collection de manera local o en un pipeline CI/CD.

Real-world example: validating a GET endpoint in Postman
Supongamos una API de librería con el endpoint GET /books/{id} que devuelve los detalles de un libro. El objetivo de la prueba es validar que el servicio responde con código 200 y que el cuerpo incluye campos como id, title y author con datos válidos.

En Postman, la prueba podría incluir aserciones como:

js
pm.test("Status code is 200", function () {
pm.response.to.have.status(200);
});

pm.test("Response body has required fields", function () {
const json = pm.response.json();
pm.expect(json).to.have.property("id");
pm.expect(json).to.have.property("title");
pm.expect(json).to.have.property("author");
});

pm.test("Book id matches requested id", function () {
const json = pm.response.json();
const requestedId = pm.request.url.variables.get("id");
pm.expect(json.id.toString()).to.eql(requestedId);
});
Este tipo de script se ejecuta automáticamente después de cada llamada y te permite validar tanto el código de estado como la estructura del JSON.

Data-driven tests with Postman
En escenarios reales, es habitual probar el mismo endpoint con distintos datos de entrada. Postman soporta pruebas orientadas a datos usando archivos CSV o JSON, donde cada fila representa un conjunto de variables para la ejecución.

Por ejemplo, un archivo CSV podría contener varios bookId y valores esperados, y la Collection Runner los iterará de manera automática. Esto permite cubrir casos positivos y negativos (IDs válidos, inexistentes o inválidos) sin duplicar manualmente las peticiones.

Rest Assured: Java-based API testing
Rest Assured es un framework para pruebas de API en Java que simplifica el envío de peticiones HTTP y la validación de respuestas. Se integra bien con TestNG o JUnit, lo que facilita su uso dentro de suites automatizadas y pipelines de CI/CD.

Su enfoque fluido permite escribir pruebas legibles, y combinarlo con librerías como Hamcrest para aserciones expresivas sobre JSON y XML. Además, soporta múltiples métodos HTTP, autenticación, parámetros, logs y manejo de serialización/deserialización.

Real-world example: Rest Assured GET test
Tomando el mismo escenario de GET /books/{id}, una prueba en Rest Assured podría validar el status code y campos clave de la respuesta JSON.

java
import static io.restassured.RestAssured.;
import static org.hamcrest.Matchers.;
import org.testng.annotations.Test;

public class BookApiTest {

@Test
public void getBookById_shouldReturnValidBook() {
    given()
        .baseUri("https://api.example.com")
        .basePath("/books/{id}")
        .pathParam("id", 1)
    .when()
        .get()
    .then()
        .statusCode(200)
        .body("id", equalTo(1))
        .body("title", notNullValue())
        .body("author", notNullValue());
}

}
Este tipo de prueba se puede ejecutar junto con el resto del suite de tests de backend, formando parte del proceso de build.

Creating reusable components in Rest Assured
En casos reales, resulta útil extraer configuraciones repetidas como baseUri, headers comunes o autenticación a una clase base. De esta forma, las pruebas se enfocan en el comportamiento, no en el detalle de configuración de cada endpoint.

Por ejemplo, se puede definir una clase BaseApiTest que configure Rest Assured en un método @BeforeClass y luego extenderla desde las clases que representan cada módulo de la API (books, users, orders, etc.).

Testing authenticated APIs
Muchos servicios exponen endpoints protegidos mediante API keys, tokens Bearer u OAuth2. Tanto Postman como Rest Assured ofrecen soporte para este tipo de autenticación, ya sea configurando headers, usando helpers integrados o generando tokens previos a las pruebas.

En Rest Assured, por ejemplo, se puede añadir un header de autorización de forma global o en cada prueba:

java
given()
.baseUri("https://api.example.com")
.header("Authorization", "Bearer " + token)
.when()
.get("/books")
.then()
.statusCode(200);
En Postman, puedes almacenar el token en una variable de entorno y referenciarlo en el header Authorization mediante {{token}}.

Integrating API tests into CI/CD
El verdadero valor de estos marcos se ve cuando se integran en pipelines de CI/CD como GitHub Actions, Jenkins o GitLab CI. La idea es ejecutar suites de pruebas de API en cada push o antes de un despliegue para evitar que cambios en el código rompan contratos existentes.

Algunos enfoques habituales son:

Ejecutar Collections de Postman mediante Newman en un job del pipeline.

Ejecutar tests de Rest Assured con Maven/Gradle como parte del stage de test.

Publicar reportes (HTML, JUnit) como artefactos del pipeline para su revisión.

Example: running Postman tests in CI
Newman, el CLI de Postman, permite ejecutar collections dentro de un flujo automatizado. Un paso típico en un pipeline podría incluir un comando como:

bash
newman run LibraryAPI.postman_collection.json \
-e staging.postman_environment.json \
--reporters cli,junit \
--reporter-junit-export newman-report.xml
Ese reporte puede ser consumido por la plataforma de CI/CD para marcar el build como exitoso o fallido según los resultados de las pruebas.

Example: running Rest Assured in CI
Para proyectos Java, lo más habitual es ejecutar los tests de Rest Assured junto con el resto de pruebas unitarias e integradas. En un pipeline que use Maven, bastaría con un job que ejecute mvn test y recoja los informes generados.

Combinado con herramientas de reporte como surefire-report o plugins de informes HTML, es posible ver en detalle qué endpoints fallaron, qué payload se envió y cuál fue la respuesta recibida.

Putting it all together
Aplicar marcos de prueba de API en proyectos reales significa ir más allá de pruebas manuales puntuales y construir suites automatizadas que vivan junto al código. Usando Postman puedes cubrir rápidamente escenarios funcionales y colaborativos, mientras que Rest Assured te permite integrar pruebas de API directamente en tu base de código Java y pipeline de CI/CD.

Al combinar ambos enfoques, obtienes una cobertura robusta: validaciones funcionales, pruebas con datos, escenarios autenticados y ejecución continua en cada cambio. Esto se traduce en APIs más confiables, menos incidentes en producción y un ciclo de desarrollo más seguro y predecible

Securing Infrastructure as Code with Checkov: A Practical SAST Approach

Renzo Fernando LOYOLA VILCA CHOQUE — Sat, 06 Dec 2025 00:41:48 +0000

Introduction
Infrastructure as Code (IaC) has revolutionized how we manage and deploy cloud resources. However, with great power comes great responsibility. Security misconfigurations in IaC templates can lead to serious vulnerabilities in production environments. This is where Static Application Security Testing (SAST) tools like Checkov come into play.

In this article, we'll explore how to implement Checkov, a powerful open-source SAST tool, to scan and secure your Infrastructure as Code across multiple platforms including Terraform, CloudFormation, Kubernetes, and more.

What is Checkov?
Checkov is a static code analysis tool developed by Bridgecrew (now part of Palo Alto Networks) that scans infrastructure code for security and compliance misconfigurations. It supports:

Terraform
CloudFormation
Kubernetes
Helm
ARM Templates
Serverless Framework
Docker
And many more...
Why Use SAST for Infrastructure as Code?
Early Detection: Identify security issues before they reach production
Compliance: Ensure adherence to industry standards (CIS, PCI-DSS, HIPAA)
Cost Reduction: Fix issues early in the development cycle
Automation: Integrate seamlessly into CI/CD pipelines
Policy as Code: Define and enforce organizational security policies

Getting Started with Checkov
Installation
Checkov can be installed using pip:

pip install checkov
Or using Docker:

docker pull bridgecrew/checkov
Basic Usage
Scan a Terraform directory:

checkov -d /path/to/terraform
Scan a specific file:

checkov -f main.tf
Practical Example: Securing Terraform Code
Let's examine a vulnerable Terraform configuration and how Checkov identifies the issues.

Vulnerable Configuration

main.tf - INSECURE EXAMPLE

resource "aws_s3_bucket" "data_bucket" {
bucket = "my-data-bucket"

# Missing encryption
# Missing versioning
# Missing logging
}

resource "aws_security_group" "web_sg" {
name = "web-security-group"
description = "Security group for web servers"

ingress {
from_port = 0
to_port = 0
protocol = "-1"
cidr_blocks = ["0.0.0.0/0"] # Too permissive!
}
}

resource "aws_db_instance" "database" {
allocated_storage = 20
engine = "mysql"
instance_class = "db.t3.micro"
username = "admin"
password = "hardcodedpassword123" # Hardcoded password!
skip_final_snapshot = true

# Missing encryption
# Publicly accessible by default
}
Running Checkov
checkov -f main.tf --output json --output-file results.json
Checkov Output
Checkov will identify multiple security issues:

Check: CKV_AWS_18: "Ensure the S3 bucket has access logging enabled"
Check: CKV_AWS_19: "Ensure the S3 bucket has server-side encryption enabled"
Check: CKV_AWS_21: "Ensure the S3 bucket has versioning enabled"
Check: CKV_AWS_23: "Ensure Security Group does not allow ingress from 0.0.0.0/0 to port 22"
Check: CKV_AWS_16: "Ensure RDS database is encrypted at rest"
Check: CKV_AWS_41: "Ensure RDS instance has IAM authentication enabled"
Secure Configuration
Now let's fix these issues:

main.tf - SECURE VERSION

resource "aws_s3_bucket" "data_bucket" {
bucket = "my-data-bucket"
}

resource "aws_s3_bucket_versioning" "data_bucket_versioning" {
bucket = aws_s3_bucket.data_bucket.id
versioning_configuration {
status = "Enabled"
}
}

resource "aws_s3_bucket_server_side_encryption_configuration" "data_bucket_encryption" {
bucket = aws_s3_bucket.data_bucket.id

rule {
apply_server_side_encryption_by_default {
sse_algorithm = "AES256"
}
}
}

resource "aws_s3_bucket_logging" "data_bucket_logging" {
bucket = aws_s3_bucket.data_bucket.id

target_bucket = aws_s3_bucket.log_bucket.id
target_prefix = "log/"
}

resource "aws_security_group" "web_sg" {
name = "web-security-group"
description = "Security group for web servers"

ingress {
from_port = 443
to_port = 443
protocol = "tcp"
cidr_blocks = ["10.0.0.0/8"] # Restricted to internal network
}

egress {
from_port = 0
to_port = 0
protocol = "-1"
cidr_blocks = ["0.0.0.0/0"]
}
}

resource "aws_db_instance" "database" {
allocated_storage = 20
engine = "mysql"
instance_class = "db.t3.micro"
username = "admin"
password = var.db_password # Using variable instead
skip_final_snapshot = false

storage_encrypted = true
iam_database_authentication_enabled = true
publicly_accessible = false

backup_retention_period = 7
enabled_cloudwatch_logs_exports = ["error", "general", "slowquery"]
}
Integrating Checkov into CI/CD
GitHub Actions Example
name: IaC Security Scan

on: [push, pull_request]

jobs:
checkov:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v3

  - name: Set up Python
    uses: actions/setup-python@v4
    with:
      python-version: '3.9'

  - name: Install Checkov
    run: pip install checkov

  - name: Run Checkov
    run: |
      checkov -d . --output cli --output json --output-file checkov-report.json

  - name: Upload results
    uses: actions/upload-artifact@v3
    if: always()
    with:
      name: checkov-report
      path: checkov-report.json

GitLab CI Example
checkov:
stage: test
image: bridgecrew/checkov:latest
script:
- checkov -d . --output cli --output junitxml --output-file checkov-report.xml
artifacts:
reports:
junit: checkov-report.xml
Custom Policies
Checkov allows you to create custom policies using Python:

from checkov.common.models.enums import CheckResult, CheckCategories
from checkov.terraform.checks.resource.base_resource_check import BaseResourceCheck

class S3BucketEncryption(BaseResourceCheck):
def init(self):
name = "Ensure S3 bucket is encrypted with KMS"
id = "CKV_AWS_CUSTOM_1"
supported_resources = ['aws_s3_bucket']
categories = [CheckCategories.ENCRYPTION]
super().init(name=name, id=id, categories=categories,
supported_resources=supported_resources)

def scan_resource_conf(self, conf):
    if 'server_side_encryption_configuration' in conf:
        encryption_config = conf['server_side_encryption_configuration'][0]
        if 'rule' in encryption_config:
            rule = encryption_config['rule'][0]
            if 'apply_server_side_encryption_by_default' in rule:
                encryption = rule['apply_server_side_encryption_by_default'][0]
                if encryption.get('sse_algorithm') == ['aws:kms']:
                    return CheckResult.PASSED
    return CheckResult.FAILED

check = S3BucketEncryption()
Best Practices
Run Checkov Early: Integrate it into your development workflow
Use Suppressions Wisely: Document why certain checks are suppressed
Keep Checkov Updated: New checks are added regularly
Set Baseline: Use --baseline to track improvements over time
Combine with Other Tools: Use alongside dynamic testing and manual reviews
Educate Your Team: Ensure developers understand the security implications
Suppressing False Positives
Sometimes you need to suppress legitimate findings:

resource "aws_security_group" "special_case" {
name = "special-sg"

#checkov:skip=CKV_AWS_23:This SG is for internal load balancer
ingress {
from_port = 80
to_port = 80
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
}
}
Measuring Success
Track these metrics to measure the effectiveness of Checkov:

Vulnerability Detection Rate: Number of issues found per scan
Fix Time: Time from detection to remediation
False Positive Rate: Percentage of findings that are not actual issues
Coverage: Percentage of infrastructure code being scanned
Compliance Score: Pass rate against security benchmarks
Conclusion
Implementing SAST tools like Checkov is essential for maintaining secure infrastructure as code. By catching security issues early in the development cycle, you can:

Reduce security risks in production
Ensure compliance with industry standards
Foster a security-first culture
Save time and money on remediation
Start small by integrating Checkov into one project, measure the results, and gradually expand coverage across your organization. Security is a journey, not a destination, and tools like Checkov are invaluable companions along the way.

References
Checkov Official Documentation
OWASP Source Code Analysis Tools
Terraform Security Best Practices
CIS Benchmarks

Dominando las Pruebas de API con Postman: Ejemplos del Mundo Real

Renzo Fernando LOYOLA VILCA CHOQUE — Thu, 04 Dec 2025 13:04:09 +0000

Introducción

En el desarrollo de software moderno, las APIs (Interfaces de Programación de Aplicaciones) son la columna vertebral de la comunicación entre sistemas. Postman se ha consolidado como una de las herramientas más populares y poderosas para probar, documentar y automatizar APIs. En este artículo, exploraremos cómo aplicar Postman en escenarios del mundo real, con ejemplos prácticos que puedes implementar inmediatamente.

¿Por qué Postman?

Postman no es solo un cliente HTTP; es una plataforma completa para el desarrollo de APIs que ofrece:

Interfaz intuitiva: Ideal para principiantes y expertos
Automatización de pruebas: Scripts JavaScript para validaciones complejas
Colecciones organizadas: Agrupa solicitudes relacionadas
Variables de entorno: Facilita el cambio entre dev, staging y producción
Integración CI/CD: Compatible con Newman para pipelines automatizados
Colaboración en equipo: Espacios de trabajo compartidos

Caso de Uso 1: Prueba de API RESTful de E-commerce

Imaginemos que estamos probando una API de una tienda en línea que gestiona productos.

Escenario: Obtener lista de productos

// GET https://api.tienda.com/v1/productos

// En la pestaña "Tests" de Postman:
pm.test("El código de estado es 200", function () {
    pm.response.to.have.status(200);
});

pm.test("La respuesta es JSON", function () {
    pm.response.to.be.json;
});

pm.test("La respuesta contiene productos", function () {
    const jsonData = pm.response.json();
    pm.expect(jsonData).to.be.an('array');
    pm.expect(jsonData.length).to.be.above(0);
});

pm.test("Cada producto tiene campos requeridos", function () {
    const productos = pm.response.json();
    productos.forEach(producto => {
        pm.expect(producto).to.have.property("id");
        pm.expect(producto).to.have.property("nombre");
        pm.expect(producto).to.have.property("precio");
        pm.expect(producto).to.have.property("stock");
    });
});

Escenario: Crear un nuevo producto (POST)

// POST https://api.tienda.com/v1/productos
// Body (JSON):
{
    "nombre": "Laptop Dell XPS 15",
    "precio": 1299.99,
    "categoria": "Electrónica",
    "stock": 25
}

// Tests:
pm.test("Producto creado exitosamente - 201", function () {
    pm.response.to.have.status(201);
});

pm.test("La respuesta contiene el ID del producto", function () {
    const jsonData = pm.response.json();
    pm.expect(jsonData).to.have.property("id");

    // Guardar el ID para usar en solicitudes posteriores
    pm.environment.set("producto_id", jsonData.id);
});

pm.test("El precio se guardó correctamente", function () {
    const jsonData = pm.response.json();
    pm.expect(jsonData.precio).to.eql(1299.99);
});

Caso de Uso 2: Autenticación y Autorización

Las APIs del mundo real requieren autenticación. Veamos cómo manejar tokens JWT.

Paso 1: Login y captura de token

// POST https://api.tienda.com/v1/auth/login
// Body:
{
    "email": "usuario@ejemplo.com",
    "password": "password123"
}

// Tests:
pm.test("Login exitoso", function () {
    pm.response.to.have.status(200);
});

pm.test("Token JWT recibido", function () {
    const jsonData = pm.response.json();
    pm.expect(jsonData).to.have.property("token");

    // Guardar el token en variable de entorno
    pm.environment.set("jwt_token", jsonData.token);

    // Guardar timestamp de expiración
    pm.environment.set("token_expiry", jsonData.expiresIn);
});

Paso 2: Usar el token en solicitudes protegidas

// GET https://api.tienda.com/v1/usuario/perfil
// Headers: Authorization: Bearer {{jwt_token}}

// Pre-request Script para verificar token:
const token = pm.environment.get("jwt_token");

if (!token) {
    throw new Error("No hay token de autenticación. Ejecuta primero el login.");
}

// Tests:
pm.test("Acceso autorizado al perfil", function () {
    pm.response.to.have.status(200);
});

pm.test("Datos del usuario son correctos", function () {
    const usuario = pm.response.json();
    pm.expect(usuario).to.have.property("email");
    pm.expect(usuario).to.have.property("nombre");
    pm.expect(usuario.rol).to.eql("admin");
});

Conclusiones

Postman es mucho más que una herramienta para enviar solicitudes HTTP. Como hemos visto en estos ejemplos del mundo real:

Validación robusta: Podemos verificar códigos de estado, estructura de datos y lógica de negocio
Flujos complejos: Encadenamiento de solicitudes con variables dinámicas
Automatización: Integración perfecta con pipelines CI/CD mediante Newman
Colaboración: Espacios de trabajo compartidos facilitan el trabajo en equipo
Documentación viva: Las colecciones sirven como documentación ejecutable

Recursos Adicionales

Sobre el autor: Este artículo forma parte del Trabajo de Investigación N° 02 sobre Comparación de Frameworks de Pruebas de API, desarrollado como parte del curso de Calidad y Pruebas de Software.

Construyendo un Servidor MCP: Conectando Claude y VSCode a Herramientas Externas

Renzo Fernando LOYOLA VILCA CHOQUE — Thu, 04 Dec 2025 01:16:02 +0000

Introducción

El Protocolo de Contexto de Modelo (MCP) es un protocolo abierto revolucionario desarrollado por Anthropic que permite a asistentes de IA como Claude conectarse con fuentes de datos externas y herramientas. En este artículo, te guiaré a través de la construcción de tu propio servidor MCP que puede ser utilizado con Claude Desktop, VSCode y otros clientes compatibles.

¿Qué es MCP?

MCP proporciona una forma estandarizada para que los asistentes de IA interactúen con sistemas externos. Piensa en él como un adaptador universal que permite a Claude:

Acceder a bases de datos y APIs
Leer y escribir archivos
Ejecutar comandos
Interactuar con servicios web

El protocolo define una arquitectura cliente-servidor donde:

Clientes MCP (como Claude Desktop o VSCode) se conectan a servidores
Servidores MCP exponen capacidades específicas (recursos, herramientas y prompts)
La comunicación ocurre a través de JSON-RPC 2.0 sobre stdio o HTTP

Descripción General de la Arquitectura

Un servidor MCP consta de tres componentes principales:

1. Recursos

Los recursos son fuentes de datos que el servidor puede proporcionar a los clientes. Pueden ser:

Archivos de un sistema de archivos
Registros de bases de datos
Respuestas de APIs
Flujos de datos en tiempo real

2. Herramientas

Las herramientas son funciones que el cliente puede invocar a través del servidor:

Ejecutar comandos del sistema
Realizar cálculos
Interactuar con APIs externas
Manipular datos

3. Prompts

Los prompts son plantillas predefinidas que ayudan a estructurar las interacciones:

Plantillas de consultas
Patrones de comandos
Instrucciones de flujo de trabajo

Construyendo tu Primer Servidor MCP

Construyamos un servidor MCP simple paso a paso. Para este ejemplo, usaré Python, pero los servidores MCP pueden construirse en cualquier lenguaje.

Requisitos Previos

pip install mcp

Estructura Básica del Servidor

from mcp.server import Server
from mcp.types import Resource, Tool
import asyncio

app = Server("my-mcp-server")

@app.list_resources()
async def list_resources() -> list[Resource]:
    return [
        Resource(
            uri="file:///example.txt",
            name="Archivo de Ejemplo",
            mimeType="text/plain"
        )
    ]

@app.read_resource()
async def read_resource(uri: str) -> str:
    if uri == "file:///example.txt":
        return "¡Hola desde el Servidor MCP!"
    raise ValueError(f"Recurso desconocido: {uri}")

@app.list_tools()
async def list_tools() -> list[Tool]:
    return [
        Tool(
            name="saludar",
            description="Saludar a alguien por su nombre",
            inputSchema={
                "type": "object",
                "properties": {
                    "nombre": {"type": "string"}
                },
                "required": ["nombre"]
            }
        )
    ]

@app.call_tool()
async def call_tool(name: str, arguments: dict) -> str:
    if name == "saludar":
        return f"¡Hola, {arguments['nombre']}!"
    raise ValueError(f"Herramienta desconocida: {name}")

if __name__ == "__main__":
    asyncio.run(app.run())

Conectando a Claude Desktop

Para usar tu servidor MCP con Claude Desktop, necesitas configurarlo en la configuración de Claude:

Abre la configuración de Claude Desktop
Navega a la sección "Developer"
Agrega la configuración de tu servidor:

{
  "mcpServers": {
    "mi-servidor": {
      "command": "python",
      "args": ["ruta/a/tu/servidor.py"]
    }
  }
}

Reinicia Claude Desktop
Las herramientas y recursos de tu servidor ahora estarán disponibles para Claude

Conectando a VSCode

Para la integración con VSCode, puedes usar la extensión MCP:

Instala la extensión MCP desde el marketplace
Configura tu servidor en .vscode/mcp.json:

{
  "servers": [
    {
      "name": "mi-servidor",
      "command": "python",
      "args": ["ruta/a/tu/servidor.py"]
    }
  ]
}

Casos de Uso del Mundo Real

Aquí hay algunas aplicaciones prácticas para servidores MCP:

Acceso a Bases de Datos

Crea un servidor que permita a Claude consultar tus bases de datos de forma segura:

@app.list_tools()
async def list_tools():
    return [Tool(name="consultar_bd", description="Ejecutar consultas SQL")]

Operaciones del Sistema de Archivos

Construye un servidor que gestione archivos de proyecto:

@app.list_resources()
async def list_resources():
    return [Resource(uri=f"file:///{archivo}") for archivo in os.listdir()]

Integración con APIs

Conecta Claude a APIs externas:

@app.call_tool()
async def call_tool(name, args):
    if name == "obtener_datos":
        response = await http_client.get(args['url'])
        return response.json()

Mejores Prácticas

Seguridad Primero: Siempre valida las entradas y sanitiza las salidas
Manejo de Errores: Proporciona mensajes de error claros
Documentación: Documenta tus herramientas y recursos exhaustivamente
Rendimiento: Usa async/await para operaciones de I/O
Pruebas: Prueba tu servidor con diferentes clientes

Repositorio de Ejemplo

Puedes encontrar un ejemplo completo y funcional en mi repositorio de GitHub:

Repositorio: https://github.com/renzoloyola/MCP-Server

Este repositorio incluye:

Implementación básica del servidor MCP
Ejemplos de configuración para Claude y VSCode
Documentación e instrucciones de configuración
Casos de uso de ejemplo

Conclusión

Construir servidores MCP abre posibilidades infinitas para extender las capacidades de los asistentes de IA. Ya sea que te estés conectando a bases de datos, sistemas de archivos o APIs externas, MCP proporciona una forma estandarizada y poderosa de hacer que tus datos y herramientas sean accesibles para la IA.

El Protocolo de Contexto de Modelo sigue evolucionando, y el ecosistema está creciendo rápidamente. Al crear tus propios servidores MCP, puedes personalizar Claude y otros clientes compatibles para que se ajusten a tus necesidades y flujos de trabajo específicos.

Recursos

¿Has construido un servidor MCP? ¡Comparte tu experiencia en los comentarios!