DEV Community: RODRIGO SIDNEY COLQUE QUISPE

Building and Deploying an Interactive Analytics Dashboard with Streamlit, GitHub Actions, and Streamlit Community Cloud

RODRIGO SIDNEY COLQUE QUISPE — Thu, 22 Oct 2026 23:02:49 +0000

How to create an executive business intelligence dashboard in pure Python, automate continuous integration with GitHub Actions, and deploy live to the cloud with zero-downtime automation.

Published on: Medium / Dev.to / Hashnode

Reading Time: 8 min read

Tags: #python #datascience #streamlit #devops #cicd #cloud #plotly

GitHub Repository: https://github.com/Rodrig0496/AG-01-Building-and-Deploying-an-Interactive-Analytics-Dashboard

Live Demo: https://ag-01-analytics-dashboard.streamlit.app

🚀 Introduction

In today’s data-driven landscape, static PDF reports and spreadsheet exports are no longer sufficient for business decision-makers. Executives and operational teams expect interactive, real-time, and accessible analytical dashboards that allow them to filter date ranges, explore regional performance, and drill down into granular KPIs on demand.

Historically, developing custom analytical web applications required a full-stack engineering team proficient in JavaScript (React/Vue), backend APIs (FastAPI/Flask), CSS styling, and complex cloud infrastructure.

While tools like Dash (Plotly), R Shiny, Bokeh, and static charting libraries like Seaborn each have their distinct strengths:

Seaborn / Matplotlib: Great for exploratory static exploratory charts in Jupyter Notebooks, but lack built-in web reactivity.
Bokeh: Powerful for interactive web canvas plots, but requires significant boilerplate for complex app UI states.
Dash: Highly customizable and production-grade, but demands deep familiarity with HTML/CSS components and reactive callback decorators.
Shiny for Python: Excellent reactive paradigm, but still carries a steeper learning curve for teams coming strictly from Python data analysis.

Enter Streamlit: the open-source Python framework that has revolutionized how data scientists and engineers turn data scripts into shareable web applications in minutes, using 100% pure Python.

In this guide, we walk through the complete end-to-end lifecycle:

Designing a production-grade Executive Sales & KPI Dashboard using Streamlit and Plotly.
Structuring a clean, public open-source repository.
Automating validation and testing through CI/CD pipelines using GitHub Actions.
Deploying to a public Cloud / SaaS platform (Streamlit Community Cloud) with automated continuous deployment.

📐 System Architecture & Workflow

The architecture follows modern DevOps and GitOps practices for data applications:

flowchart LR
    A[Local Development<br>Streamlit + Plotly] -->|git push| B[Public GitHub Repository]
    B -->|Triggers| C[GitHub Actions CI<br>Linting & Smoke Tests]
    B -->|Webhook Sync| D[Streamlit Community Cloud<br>Public SaaS Hosting]
    D --> E[Live Web Dashboard<br>Accessible Worldwide]

Key Workflow Pillars:

Developer Experience: Write clean Python code with reactive data caching (@st.cache_data).
Quality Assurance: GitHub Actions automatically lints code and runs headless smoke tests on every push.
Continuous Deployment (CD): Streamlit Community Cloud watches the main branch and deploys updates instantaneously with zero manual server configuration.

📁 Repository Structure

A clean, reproducible directory structure is vital for both collaboration and automated cloud buildpacks:

AG-01-Building-and-Deploying-an-Interactive-Analytics-Dashboard/
├── .github/
│   └── workflows/
│       └── ci.yml               # Automated CI pipeline (linting & headless tests)
├── .streamlit/
│   └── config.toml              # UI styling theme & production server flags
├── app.py                       # Main Streamlit dashboard application
├── requirements.txt             # Pinned Python package dependencies
├── .gitignore                   # Ignore caches, virtual environments & secrets
└── README.md                    # Project documentation, live links & setup guide

🛠️ Step 1: Building the Interactive Streamlit Dashboard

Our application, app.py, provides a comprehensive executive analytics experience:

KPI Metric Scorecards with comparative deltas.
Interactive Time-Series Chart tracking Gross Revenue vs. Net Profit.
Market Share Donut Chart highlighting regional distribution.
Category Performance Grouped Bar Chart analyzing product lines.
Segment Profitability Scatter Plot correlating volume with profit margins.
Dynamic Sidebar Filters with multi-selects and date-range pickers.
In-Memory CSV Exporter for tabular data inspection.

1.1 Configuring Page Layout & Custom Styling

We initialize a wide layout and apply subtle dark-mode styling adjustments using Streamlit's native st.set_page_config and injected CSS:

import streamlit as st
import pandas as pd
import numpy as np
import plotly.express as px
import plotly.graph_objects as go
from datetime import datetime, timedelta

st.set_page_config(
    page_title="Executive Sales & KPI Dashboard",
    page_icon="📊",
    layout="wide",
    initial_sidebar_state="expanded",
)

1.2 Optimized Data Caching with `@st.cache_data`

One of Streamlit's most powerful features is intelligent caching. By decorating our data ingestion function with @st.cache_data, Streamlit memoizes the dataset in memory, preventing expensive computations from re-running on every filter click:

@st.cache_data(ttl=3600)
def generate_sample_sales_data(num_records: int = 1500) -> pd.DataFrame:
    np.random.seed(42)
    end_date = datetime.now()
    start_date = end_date - timedelta(days=365)

    date_range = [
        start_date + timedelta(days=int(d))
        for d in np.random.uniform(0, 365, num_records)
    ]

    regions = ["North America", "Europe", "Asia-Pacific", "Latin America", "Middle East"]
    categories = {
        "Cloud Solutions": ["Enterprise SaaS", "Data Storage", "Cloud Compute", "Cybersecurity"],
        "Hardware": ["Servers", "Workstations", "Networking Gear", "IoT Hubs"],
        "Professional Services": ["Cloud Migration", "AI Consulting", "Managed Support", "DevOps Audit"]
    }

    # Generate realistic revenue and profit margins
    units_sold = np.random.randint(1, 15, size=num_records)
    base_unit_prices = np.random.uniform(150, 4500, size=num_records)
    gross_sales = np.round(units_sold * base_unit_prices, 2)
    profit = np.round(gross_sales * np.random.uniform(0.15, 0.42, size=num_records), 2)

    data = pd.DataFrame({
        "Order_ID": [f"ORD-{10000 + i}" for i in range(num_records)],
        "Date": pd.to_datetime(date_range),
        "Region": np.random.choice(regions, size=num_records),
        "Customer_Segment": np.random.choice(["Enterprise", "Mid-Market", "SMB", "Government"], size=num_records),
        "Category": np.random.choice(list(categories.keys()), size=num_records),
        "Gross_Sales": gross_sales,
        "Net_Profit": profit,
    })
    data["Month_Year"] = data["Date"].dt.to_period("M").dt.to_timestamp()
    return data.sort_values("Date")

raw_data = generate_sample_sales_data()

1.3 Interactive Sidebar Controls & Filtering

Streamlit's declarative syntax allows us to construct interactive UI controls directly in the sidebar:

with st.sidebar:
    st.markdown("### ⚙️ Filter Controls")

    # Time Window Filter
    min_date = raw_data["Date"].min().date()
    max_date = raw_data["Date"].max().date()
    date_selection = st.date_input("Select Time Window", value=(min_date, max_date))

    # Geographic Multi-Select
    selected_regions = st.multiselect(
        "Geographic Regions",
        options=sorted(raw_data["Region"].unique()),
        default=sorted(raw_data["Region"].unique())
    )

# Filter logic
filtered_data = raw_data[
    (raw_data["Date"].dt.date >= date_selection[0]) &
    (raw_data["Date"].dt.date <= date_selection[1]) &
    (raw_data["Region"].isin(selected_regions))
]

1.4 High-Impact Visualizations with Plotly

Combining Streamlit with Plotly allows us to generate responsive, hardware-accelerated interactive charts. For example, rendering our monthly revenue trajectory:

monthly_trend = filtered_data.groupby("Month_Year")[["Gross_Sales", "Net_Profit"]].sum().reset_index()

fig_trend = go.Figure()
fig_trend.add_trace(go.Scatter(
    x=monthly_trend["Month_Year"],
    y=monthly_trend["Gross_Sales"],
    name="Gross Sales",
    mode="lines+markers",
    line=dict(color="#6366F1", width=3),
    fill="tozeroy",
    fillcolor="rgba(99, 102, 241, 0.15)"
))
fig_trend.update_layout(template="plotly_dark", hovermode="x unified")
st.plotly_chart(fig_trend, use_container_width=True)

⚙️ Step 2: Continuous Integration & Automated Testing

Deploying data applications without automated tests is risky. A broken library version or syntax typo can crash your production dashboard. We implement a continuous integration workflow using GitHub Actions in .github/workflows/ci.yml.

Every time a team member pushes code or opens a Pull Request to main, the workflow executes:

name: Streamlit Dashboard CI/CD Pipeline

on:
  push:
    branches: [ main, master ]
  pull_request:
    branches: [ main, master ]

jobs:
  validate-and-test:
    runs-on: ubuntu-latest
    steps:
      - name: 📥 Checkout Repository
        uses: actions/checkout@v4

      - name: 🐍 Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: "3.11"
          cache: "pip"

      - name: 📦 Install Dependencies
        run: |
          python -m pip install --upgrade pip
          pip install -r requirements.txt
          pip install flake8

      - name: 🔍 Lint Code with Flake8
        run: |
          flake8 . --count --select=E9,F63,F7,F82 --show-source --statistics

      - name: 🧪 Smoke Test App Compilation
        run: |
          python -c "import app; print('App syntax and imports verified successfully!')"

      - name: 🚀 Verify Headless Streamlit Startup
        run: |
          timeout 10s streamlit run app.py --server.headless=true --server.port=8501 || [ $? -eq 124 ]
          echo "Streamlit successfully launched in headless mode!"

Why This Automated CI Step Matters:

Catches Dependency Conflicts: Guarantees that requirements.txt contains valid, installable packages.
Headless Smoke Test: Validates that the Streamlit server boots up and serves traffic without throwing unhandled startup exceptions.
Guards Production: Prevents broken code from being pushed to the live cloud platform.

☁️ Step 3: Deploying to a Public Cloud / SaaS Platform

For public deployment, we select Streamlit Community Cloud—a native public cloud SaaS platform providing global hosting, zero-configuration SSL, and native GitOps integration.

Step-by-Step Deployment Walkthrough:

Push your code to GitHub:

   git init
   git add .
   git commit -m "feat: complete executive streamlit dashboard with CI pipeline"
   git branch -M main
   git remote add origin https://github.com/Rodrig0496/AG-01-Building-and-Deploying-an-Interactive-Analytics-Dashboard.git
   git push -u origin main

Connect Streamlit Community Cloud:
- Navigate to share.streamlit.io.
- Sign in using your GitHub account.
Deploy the Application:
- Click on the "New app" button.
- Select your repository: Rodrig0496/AG-01-Building-and-Deploying-an-Interactive-Analytics-Dashboard.
- Set the Branch to: main.
- Set the Main file path to: app.py.
- (Optional) Customize your App URL subdomain: https://ag-01-analytics-dashboard.streamlit.app.
- Click "Deploy!".
Automated Continuous Deployment (CD):
Streamlit Community Cloud registers a webhook with your GitHub repository. Whenever you or a teammate pushes commits to main:
- The GitHub Actions CI pipeline runs and validates your code.
- Streamlit Cloud automatically pulls the new commit, installs updated dependencies, and performs a live rolling reload without downtime.

(Alternative Cloud Providers: You can also deploy this containerized app to **Render, **Hugging Face Spaces, **AWS App Runner, or **Google Cloud Run* using a lightweight Dockerfile).*

🔗 Live Application & Public Repository

The source code and live deployed instance are publicly accessible:

Resource	Link
📦 Public GitHub Repository	https://github.com/Rodrig0496/AG-01-Building-and-Deploying-an-Interactive-Analytics-Dashboard
🚀 Live Cloud Dashboard	https://ag-01-analytics-dashboard.streamlit.app
📄 Automated CI/CD Workflow	.github/workflows/ci.yml

💡 Lessons Learned & Best Practices

Always Use Caching: Uncached data loading leads to laggy interactions because Streamlit re-executes scripts top-to-bottom on state changes. Use @st.cache_data for dataframes and @st.cache_resource for database connections or ML models.
Containerize Server Configurations: Use .streamlit/config.toml to lock in headless mode and consistent branding colors so your app looks identical locally and in the cloud.
Automate Smoke Testing: The timeout 10s streamlit run test in GitHub Actions saves hours of debugging by catching missing cloud packages before your users see an error screen.
Design for Responsiveness: Utilize st.columns() and Plotly's use_container_width=True to ensure your dashboard renders gracefully on both ultra-wide desktop monitors and mobile devices.

🎯 Conclusion

Modern data professionals need more than just analytical algorithms—they need the ability to communicate insights effectively through accessible web applications.

By combining Streamlit for rapid UI development, Plotly for interactive visualization, GitHub Actions for automated CI testing, and Streamlit Community Cloud for automated continuous deployment, you can deliver production-grade data products in hours instead of weeks.

💬 Let's Connect!

Have questions or suggestions on dashboard architecture or cloud automation? Feel free to leave a comment below or connect on LinkedIn / GitHub. If you found this article helpful, don't forget to leave a 👏 or star the repository!

Testing Management Tools: A Comparative Guide and Real-World Reporting

RODRIGO SIDNEY COLQUE QUISPE — Sat, 27 Jun 2026 15:58:53 +0000

Testing Management Tools: A Comparative Guide and Real-World Reporting

As software projects grow, keeping track of what has been tested, what failed, and what needs to be re-tested becomes a logistical nightmare. Spreadsheets just don't cut it anymore. This is where Testing Management and Reporting Tools come into play.

In this article, we will compare three of the most popular test management tools in the industry and provide a real-world code example showing how to generate a management dashboard locally for your automated tests.

1. TestRail

TestRail is a dedicated, standalone web-based test case management tool.

Pros: Incredible UI/UX, highly customizable, excellent reporting metrics, and a robust REST API.
Cons: Can be expensive for large teams, not natively built inside Jira (though it has an integration plugin).
Best for: Teams that want a dedicated, powerful platform solely for QA and testing.

2. Zephyr Scale (formerly TM4J)

Zephyr Scale is built directly into Jira.

Pros: Seamless Jira integration (issues, epics, and bugs are natively linked to tests), very cost-effective if you already use Jira.
Cons: The UI can feel cluttered since it lives inside Jira. Slower performance on massive test suites compared to standalone tools.
Best for: Agile teams already heavily invested in the Atlassian (Jira) ecosystem.

3. Pytest-HTML / Local Reporting Tools

While TestRail and Zephyr are enterprise solutions, many developers use open-source local reporting plugins like pytest-html or Allure to generate self-contained HTML management dashboards from their test runs.

Pros: 100% Free, runs offline on your own machine, extremely fast, generates a beautiful visual HTML dashboard.
Cons: Doesn't support manual test case writing (purely for automated tests), and doesn't store historical data across years unless you save the files.
Best for: Individual developers, students, or teams that need instant, visual reporting directly from their CI pipeline without paying for a SaaS tool.

Real-World Code Example: Generating a Test Dashboard Locally

Let's look at how we can implement a local reporting/management tool using Python and the pytest-html plugin. This will allow us to run tests and instantly get a professional HTML dashboard showing exactly what passed, what failed, and how long it took.

The Code

First, we install Pytest and the HTML reporting plugin:

pip install pytest pytest-html

Next, we write some simple tests for a mock Login system in a file called test_login.py:

import pytest

def test_successful_login():
    """
    Test a valid login scenario.
    """
    username = "admin"
    password = "password123"

    # Mock login logic
    is_logged_in = (username == "admin" and password == "password123")

    # We expect this test to PASS
    assert is_logged_in == True

def test_failed_login():
    """
    Test an invalid login scenario.
    """
    username = "admin"
    password = "wrongpassword"

    is_logged_in = (username == "admin" and password == "password123")

    # We expect this test to FAIL (because it returns False)
    assert is_logged_in == True

Execution and Dashboard Generation

Normally, you would run pytest and get a text output in the terminal. To use our reporting tool, we pass a special flag to generate the dashboard:

python -m pytest test_login.py --html=report.html --self-contained-html

When this runs, pytest-html intercepts the results and creates a visually appealing file named report.html. If you open this file in Google Chrome or any browser, you will see a full Test Management dashboard displaying:

Environment metrics (Python version, OS).
A Summary table (1 Passed, 1 Failed).
The exact logs and tracebacks for the failed tests.

Public Example Repository:
You can find the complete, runnable code example for this integration in this GitHub repository:
🔗 https://github.com/Rodrig0496/U3_Article.git

By automating your test reporting, your QA managers get real-time visibility into the health of the application without the developers or testers having to do any manual data entry.

Applying API Testing Frameworks in the Real World: A Practical Guide with Pytest

RODRIGO SIDNEY COLQUE QUISPE — Sat, 27 Jun 2026 15:40:37 +0000

In today's interconnected software landscape, Application Programming Interfaces (APIs) are the bridges that allow different systems to communicate. With the growing reliance on microservices and third-party integrations, ensuring that your APIs are robust, secure, and performant is no longer optional—it's critical.

This is where API testing frameworks come in. In this article, we'll explore how to apply API testing in the real world using Python and Pytest, one of the most popular and powerful testing frameworks available.

Why Do We Need API Testing Frameworks?

Manual testing using tools like Postman or Insomnia is great for exploration, but it doesn't scale. When you have hundreds of endpoints and continuous integration/continuous deployment (CI/CD) pipelines, you need automated frameworks to:

Ensure Reliability: Catch breaking changes before they reach production.
Validate Business Logic: Verify that the API returns the correct data for both valid and invalid inputs.
Check Performance and Security: Ensure the API can handle load and is secure against common vulnerabilities.

The Tooling: Python, Pytest, and Requests

For our real-world example, we'll use:

Python: A versatile language widely used for test automation.
Pytest: A mature testing framework that makes writing small tests easy, yet scales to support complex functional testing.
Requests: The elegant and simple HTTP library for Python to make API calls.

Real-World Scenario: Testing a User Management API

Imagine we are building a backend for a social media application. We have an API endpoint to retrieve user profiles. We need to ensure that:

A valid request returns a 200 OK status and the correct user data structure.
Requesting a non-existent user returns a 404 Not Found status.

Let's write tests for a free, public mock API (https://jsonplaceholder.typicode.com).

Step 1: Setting up the environment

First, install the necessary packages:

pip install pytest requests

Step 2: Writing our first tests

Create a file named test_users_api.py and add the following code:

import requests
import pytest

BASE_URL = "https://jsonplaceholder.typicode.com"

def test_get_valid_user():
    """
    Test that retrieving an existing user returns a 200 status code
    and the correct data structure.
    """
    user_id = 2
    response = requests.get(f"{BASE_URL}/users/{user_id}")

    # 1. Assert Status Code
    assert response.status_code == 200, f"Expected 200, but got {response.status_code}"

    # 2. Parse JSON response
    response_data = response.json()

    # 3. Assert Data Structure and Content
    assert response_data["id"] == user_id
    assert "email" in response_data
    assert "name" in response_data

def test_get_nonexistent_user():
    """
    Test that retrieving a user that does not exist returns a 404 status code.
    """
    user_id = 9999  # Assuming this user doesn't exist
    response = requests.get(f"{BASE_URL}/users/{user_id}")

    # Assert Status Code
    assert response.status_code == 404, f"Expected 404, but got {response.status_code}"

    # Check that the response is empty as expected by this mock API
    assert response.json() == {}

Step 3: Running the tests

Execute the tests in your terminal using the pytest command:

python -m pytest test_users_api.py -v

Output:

============================= test session starts ==============================
...
test_users_api.py::test_get_valid_user PASSED                            [ 50%]
test_users_api.py::test_get_nonexistent_user PASSED                      [100%]

============================== 2 passed in 0.45s ===============================

Advanced Real-World Practices

While the example above is simple, real-world API testing frameworks incorporate more advanced patterns:

1. Data-Driven Testing with `@pytest.mark.parametrize`

Instead of writing separate functions for every edge case, you can parameterize your tests.

@pytest.mark.parametrize("user_id, expected_status", [
    (1, 200),
    (2, 200),
    (9999, 404)
])
def test_get_users_status(user_id, expected_status):
    response = requests.get(f"{BASE_URL}/users/{user_id}")
    assert response.status_code == expected_status

2. Authentication and Setup with Pytest Fixtures

If your API requires authentication (e.g., Bearer tokens), you shouldn't log in inside every test. Use fixtures to handle setup and teardown.

@pytest.fixture(scope="session")
def api_token():
    # Code to authenticate and get token
    # login_response = requests.post(f"{BASE_URL}/login", json={"email": "...", "password": "..."})
    # return login_response.json()["token"]
    return "mock_token_123"

def test_secure_endpoint(api_token):
    headers = {"Authorization": f"Bearer {api_token}"}
    response = requests.get(f"{BASE_URL}/secure-data", headers=headers)
    # ... assertions

3. Schema Validation

In the real world, APIs evolve. Instead of manually asserting every key in a JSON response, use schema validation libraries like Cerberus or jsonschema to ensure the response payload matches the expected contract.

Conclusion

Building a robust API testing framework is an investment that pays off exponentially as your application grows. By leveraging Python, requests, and the powerful features of pytest like parametrization and fixtures, you can create a test suite that is easy to maintain, highly readable, and perfectly suited for CI/CD pipelines.

Start small, automate your most critical endpoints first, and gradually build out your coverage. Happy testing!

Applying API Testing Frameworks in the Real World: A Practical Guide with Pytest

RODRIGO SIDNEY COLQUE QUISPE — Sat, 27 Jun 2026 14:35:34 +0000

Applying API Testing Frameworks in the Real World: A Practical Guide with Pytest

This is where API testing frameworks come in. In this article, we'll explore how to apply API testing in the real world using Python and Pytest, one of the most popular and powerful testing frameworks available.

Why Do We Need API Testing Frameworks?

Ensure Reliability: Catch breaking changes before they reach production.
Validate Business Logic: Verify that the API returns the correct data for both valid and invalid inputs.
Check Performance and Security: Ensure the API can handle load and is secure against common vulnerabilities.

The Tooling: Python, Pytest, and Requests

For our real-world example, we'll use:

Python: A versatile language widely used for test automation.
Pytest: A mature testing framework that makes writing small tests easy, yet scales to support complex functional testing.
Requests: The elegant and simple HTTP library for Python to make API calls.

Real-World Scenario: Testing a User Management API

Imagine we are building a backend for a social media application. We have an API endpoint to retrieve user profiles. We need to ensure that:

A valid request returns a 200 OK status and the correct user data structure.
Requesting a non-existent user returns a 404 Not Found status.

Let's write tests for a mock API (e.g., https://reqres.in/api/users).

Step 1: Setting up the environment

First, install the necessary packages:

pip install pytest requests

Step 2: Writing our first tests

Create a file named test_users_api.py and add the following code:

import requests
import pytest

BASE_URL = "https://reqres.in/api"

def test_get_valid_user():
    """
    Test that retrieving an existing user returns a 200 status code
    and the correct data structure.
    """
    user_id = 2
    response = requests.get(f"{BASE_URL}/users/{user_id}")

    # 1. Assert Status Code
    assert response.status_code == 200, f"Expected 200, but got {response.status_code}"

    # 2. Parse JSON response
    response_data = response.json()

    # 3. Assert Data Structure and Content
    assert "data" in response_data
    assert response_data["data"]["id"] == user_id
    assert "email" in response_data["data"]
    assert "first_name" in response_data["data"]

def test_get_nonexistent_user():
    """
    Test that retrieving a user that does not exist returns a 404 status code.
    """
    user_id = 9999  # Assuming this user doesn't exist
    response = requests.get(f"{BASE_URL}/users/{user_id}")

    # Assert Status Code
    assert response.status_code == 404, f"Expected 404, but got {response.status_code}"

    # Check that the response is empty as expected by this mock API
    assert response.json() == {}

Step 3: Running the tests

Execute the tests in your terminal using the pytest command:

pytest test_users_api.py -v

Output:

============================= test session starts ==============================
...
test_users_api.py::test_get_valid_user PASSED                            [ 50%]
test_users_api.py::test_get_nonexistent_user PASSED                      [100%]

============================== 2 passed in 0.45s ===============================

Advanced Real-World Practices

While the example above is simple, real-world API testing frameworks incorporate more advanced patterns:

1. Data-Driven Testing with `@pytest.mark.parametrize`

Instead of writing separate functions for every edge case, you can parameterize your tests.

@pytest.mark.parametrize("user_id, expected_status", [
    (1, 200),
    (2, 200),
    (999, 404)
])
def test_get_users_status(user_id, expected_status):
    response = requests.get(f"{BASE_URL}/users/{user_id}")
    assert response.status_code == expected_status

2. Authentication and Setup with Pytest Fixtures

If your API requires authentication (e.g., Bearer tokens), you shouldn't log in inside every test. Use fixtures to handle setup and teardown.

@pytest.fixture(scope="session")
def api_token():
    # Code to authenticate and get token
    # login_response = requests.post(f"{BASE_URL}/login", json={"email": "...", "password": "..."})
    # return login_response.json()["token"]
    return "mock_token_123"

def test_secure_endpoint(api_token):
    headers = {"Authorization": f"Bearer {api_token}"}
    response = requests.get(f"{BASE_URL}/secure-data", headers=headers)
    # ... assertions

3. Schema Validation

Conclusion

Start small, automate your most critical endpoints first, and gradually build out your coverage. Happy testing!

Applying API Testing Frameworks in the Real World: A Practical Guide with Pytest

RODRIGO SIDNEY COLQUE QUISPE — Sat, 27 Jun 2026 14:35:34 +0000

Applying API Testing Frameworks in the Real World: A Practical Guide with Pytest

Why Do We Need API Testing Frameworks?

Ensure Reliability: Catch breaking changes before they reach production.
Validate Business Logic: Verify that the API returns the correct data for both valid and invalid inputs.
Check Performance and Security: Ensure the API can handle load and is secure against common vulnerabilities.

The Tooling: Python, Pytest, and Requests

For our real-world example, we'll use:

Python: A versatile language widely used for test automation.
Pytest: A mature testing framework that makes writing small tests easy, yet scales to support complex functional testing.
Requests: The elegant and simple HTTP library for Python to make API calls.

Real-World Scenario: Testing a User Management API

Imagine we are building a backend for a social media application. We have an API endpoint to retrieve user profiles. We need to ensure that:

A valid request returns a 200 OK status and the correct user data structure.
Requesting a non-existent user returns a 404 Not Found status.

Let's write tests for a mock API (e.g., https://reqres.in/api/users).

Step 1: Setting up the environment

First, install the necessary packages:

pip install pytest requests

Step 2: Writing our first tests

Create a file named test_users_api.py and add the following code:

import requests
import pytest

BASE_URL = "https://reqres.in/api"

def test_get_valid_user():
    """
    Test that retrieving an existing user returns a 200 status code
    and the correct data structure.
    """
    user_id = 2
    response = requests.get(f"{BASE_URL}/users/{user_id}")

    # 1. Assert Status Code
    assert response.status_code == 200, f"Expected 200, but got {response.status_code}"

    # 2. Parse JSON response
    response_data = response.json()

    # 3. Assert Data Structure and Content
    assert "data" in response_data
    assert response_data["data"]["id"] == user_id
    assert "email" in response_data["data"]
    assert "first_name" in response_data["data"]

def test_get_nonexistent_user():
    """
    Test that retrieving a user that does not exist returns a 404 status code.
    """
    user_id = 9999  # Assuming this user doesn't exist
    response = requests.get(f"{BASE_URL}/users/{user_id}")

    # Assert Status Code
    assert response.status_code == 404, f"Expected 404, but got {response.status_code}"

    # Check that the response is empty as expected by this mock API
    assert response.json() == {}

Step 3: Running the tests

Execute the tests in your terminal using the pytest command:

pytest test_users_api.py -v

Output:

============================= test session starts ==============================
...
test_users_api.py::test_get_valid_user PASSED                            [ 50%]
test_users_api.py::test_get_nonexistent_user PASSED                      [100%]

============================== 2 passed in 0.45s ===============================

Advanced Real-World Practices

While the example above is simple, real-world API testing frameworks incorporate more advanced patterns:

1. Data-Driven Testing with `@pytest.mark.parametrize`

Instead of writing separate functions for every edge case, you can parameterize your tests.

@pytest.mark.parametrize("user_id, expected_status", [
    (1, 200),
    (2, 200),
    (999, 404)
])
def test_get_users_status(user_id, expected_status):
    response = requests.get(f"{BASE_URL}/users/{user_id}")
    assert response.status_code == expected_status

2. Authentication and Setup with Pytest Fixtures

If your API requires authentication (e.g., Bearer tokens), you shouldn't log in inside every test. Use fixtures to handle setup and teardown.

@pytest.fixture(scope="session")
def api_token():
    # Code to authenticate and get token
    # login_response = requests.post(f"{BASE_URL}/login", json={"email": "...", "password": "..."})
    # return login_response.json()["token"]
    return "mock_token_123"

def test_secure_endpoint(api_token):
    headers = {"Authorization": f"Bearer {api_token}"}
    response = requests.get(f"{BASE_URL}/secure-data", headers=headers)
    # ... assertions

3. Schema Validation

Conclusion

Start small, automate your most critical endpoints first, and gradually build out your coverage. Happy testing!

Breaking the SQL Barrier: How to Build a Natural Language Database Assistant

RODRIGO SIDNEY COLQUE QUISPE — Sat, 27 Jun 2026 04:45:15 +0000

Tags: #DataEngineering #AI #Python #HuggingFace #Streamlit

For decades, SQL has been the universal language for extracting insights from databases. But there's a catch: it creates a bottleneck. Business analysts, product managers, and marketers often have to wait for data teams to write queries for them.

What if we could skip the code and just talk to our databases in plain English?

Thanks to the rapid advancements in Artificial Intelligence and Large Language Models (LLMs), this is now entirely possible. Today, I'll walk you through how I built a Text-to-SQL assistant using Python, and how you can do it too.

What is Text-to-SQL?

At its core, Text-to-SQL is an AI capability that translates conversational questions into executable SQL code. Imagine typing, "Show me all employees in the Sales department earning over 50k" and having the AI instantly generate:

SELECT * FROM employees WHERE Department = 'Sales' AND Salary > 50000;

It’s like having a senior data engineer at your fingertips 24/7.

The Tech Stack

To keep things simple and accessible, I chose a modern, lightweight stack for this project:

Hugging Face: To power the AI model (we're using t5-base-finetuned-wikiSQL).
Streamlit: To quickly build a clean, interactive user interface.
SQLite & Pandas: To handle our local mock data.

How It Works Under the Hood

1. The Brains (Hugging Face API)

Instead of training a model from scratch, we leverage Hugging Face's Inference API. By sending an HTTP request with our user's question, the API returns the translated SQL query. It's incredibly fast and requires very little code:

import requests

API_URL = "https://api-inference.huggingface.co/models/mrm8488/t5-base-finetuned-wikiSQL"

def get_sql_from_text(user_query):
    payload = {"inputs": f"translate English to SQL: {user_query}"}
    response = requests.post(API_URL, json=payload)
    return response.json()[0]['generated_text']

2. The Data Layer

For demonstration purposes, the app initializes an in-memory SQLite database loaded with some dummy employee records. This allows the app to actually execute the AI-generated SQL and prove that it works, rather than just showing the query on the screen.

3. Putting it together with Streamlit

Streamlit ties everything beautifully. We capture the user's input through a text box. When they hit "Generate", the app fetches the SQL from Hugging Face, executes it against our SQLite database using pandas.read_sql_query, and renders the final dataset directly in the browser.

Why This Matters

Tools like this represent a massive shift in data democratization. When you remove the technical barrier of SQL, you empower everyone in an organization to be data-driven, speeding up decision-making across the board.

Want to see the code in action or try running it yourself?
I've made the entire project open-source. Check out my repository here:
👉 https://github.com/FabricioRams/Research-Team-Work-N-01-SQL-AI-Database-Solutions.git

(Note: Just install the requirements and run streamlit run app.py to start chatting with your data!)

Under the Hood: How Bandit SAST Analyzes Your Python Code

RODRIGO SIDNEY COLQUE QUISPE — Tue, 21 Apr 2026 16:10:54 +0000

Abstract
While many developers use security scanners, few understand how they actually "read" code. This article explains the inner workings of Bandit, focusing on its use of the Abstract Syntax Tree (AST) to identify security patterns without ever executing a single line of code.

1. The Core Engine: AST (Abstract Syntax Tree)
Unlike a simple text search (which might give many false positives), Bandit doesn't just look for words like "password". It converts your Python code into an AST.

What is AST? It is a tree representation of the abstract syntactic structure of your source code.

Why it matters: By building a tree, Bandit understands the context. It knows if a string is just a comment or if it's actually being assigned to a sensitive variable or passed to a dangerous function like eval().

2. How the "Scanning" Happens
Bandit works through a set of plugins. Each plugin is designed to look for a specific type of vulnerability:
Blacklist Plugins: These look for the use of insecure modules (like pickle or telnetlib).
Function Call Plugins: These trigger when they see dangerous calls (like subprocess.shell=True).
Hardcoded Secret Plugins: These use heuristics to identify strings that look like passwords or API keys.

3. Severity and Confidence levels
One of Bandit's best features is its scoring system:
Severity: How bad is the bug? (Low, Medium, High).
Confidence: How sure is Bandit that this is actually a bug and not a mistake?

Why use it in the CI/CD?
The main advantage is speed. Because it doesn't need to compile or run the code, it can scan thousands of lines in seconds. Integrating it into GitHub Actions (as shown in my previous post) ensures that no "illegal" AST patterns make it into the main branch.

Conclusion
Bandit isn't just a linter; it's a security-focused parser. By understanding the structure of Python, it provides a robust first line of defense for any backend developer.

Implementing SAST in Your Infrastructure: Detecting Vulnerabilities with Checkov and GitHub Actions

RODRIGO SIDNEY COLQUE QUISPE — Tue, 21 Apr 2026 03:50:44 +0000

Abstract
This article explores the implementation of Static Application Security Testing (SAST) for Infrastructure as Code (IaC) using Checkov. We demonstrate how to identify common security misconfigurations, such as publicly accessible S3 buckets, and seamlessly integrate the scanning process into a CI/CD pipeline using GitHub Actions.

What is Checkov?
Checkov is an open-source static analysis tool (maintained by Bridgecrew / Prisma Cloud) designed specifically for Infrastructure as Code.

Unlike tools aimed at application code (like Bandit for Python), Checkov scans configuration files for misconfigurations that could lead to security vulnerabilities or compliance issues.

Why use Checkov?

Built-in policies: It comes with hundreds of out-of-the-box policies covering AWS, Azure, and GCP best practices.
Multi-framework: Supports Terraform, CloudFormation, Kubernetes, Dockerfiles, Serverless, and more.
Easy integration: Runs from the command line or directly in your CI/CD pipelines.

The Scenario: Vulnerable Infrastructure

Imagine you have a Terraform file (main.tf) where you define an S3 bucket. By mistake (or for a quick test), you configure it to have public read access:

# main.tf resource "aws_s3_bucket" "my_vulnerable_bucket" { bucket = "my-dev-test-bucket" acl = "public-read" # ❌ Security risk! }

If we deploy this, anyone on the internet could access our data. Let's make our repository catch this error before it gets merged into the main branch.

Automating with GitHub Actions
The real magic happens when we integrate Checkov into our CI/CD workflow. This way, every time someone pushes code or opens a Pull Request, Checkov will analyze the infrastructure automatically.

In your repository, create a file at .github/workflows/checkov.yml and add the following:

What exactly does this workflow do?

1. Checkout: Clones your code into the GitHub Actions virtual environment.
2. Run Checkov: Uses the official Bridgecrew action. The directory: . parameter tells it to look for infrastructure files throughout the repository.
3. soft_fail: false: This is the key to DevSecOps. If Checkov finds a failing policy (like our public bucket), the pipeline will fail, preventing vulnerable code from being integrated.

Conclusion
Shifting security to the left (Shift-Left Security) by implementing SAST in your Infrastructure as Code is no longer optional. With tools like Checkov and GitHub Actions, it's a fast and highly effective process. With just a few lines of code, you can ensure your team doesn't accidentally deploy insecure configurations.

DEV Community: RODRIGO SIDNEY COLQUE QUISPE

Building and Deploying an Interactive Analytics Dashboard with Streamlit, GitHub Actions, and Streamlit Community Cloud

🚀 Introduction

📐 System Architecture & Workflow

Key Workflow Pillars:

📁 Repository Structure

🛠️ Step 1: Building the Interactive Streamlit Dashboard

1.1 Configuring Page Layout & Custom Styling

1.2 Optimized Data Caching with @st.cache_data

1.3 Interactive Sidebar Controls & Filtering

1.4 High-Impact Visualizations with Plotly

⚙️ Step 2: Continuous Integration & Automated Testing

Why This Automated CI Step Matters:

☁️ Step 3: Deploying to a Public Cloud / SaaS Platform

Step-by-Step Deployment Walkthrough:

🔗 Live Application & Public Repository

💡 Lessons Learned & Best Practices

🎯 Conclusion

💬 Let's Connect!

Testing Management Tools: A Comparative Guide and Real-World Reporting

Testing Management Tools: A Comparative Guide and Real-World Reporting

1. TestRail

2. Zephyr Scale (formerly TM4J)

3. Pytest-HTML / Local Reporting Tools

Real-World Code Example: Generating a Test Dashboard Locally

The Code

Execution and Dashboard Generation

Applying API Testing Frameworks in the Real World: A Practical Guide with Pytest

Why Do We Need API Testing Frameworks?

The Tooling: Python, Pytest, and Requests

Real-World Scenario: Testing a User Management API

Step 1: Setting up the environment

Step 2: Writing our first tests

Step 3: Running the tests

Advanced Real-World Practices

1. Data-Driven Testing with @pytest.mark.parametrize

2. Authentication and Setup with Pytest Fixtures

3. Schema Validation

Conclusion

Applying API Testing Frameworks in the Real World: A Practical Guide with Pytest

Applying API Testing Frameworks in the Real World: A Practical Guide with Pytest

Why Do We Need API Testing Frameworks?

The Tooling: Python, Pytest, and Requests

Real-World Scenario: Testing a User Management API

Step 1: Setting up the environment

Step 2: Writing our first tests

Step 3: Running the tests

Advanced Real-World Practices

1. Data-Driven Testing with @pytest.mark.parametrize

2. Authentication and Setup with Pytest Fixtures

3. Schema Validation

Conclusion

Applying API Testing Frameworks in the Real World: A Practical Guide with Pytest

Applying API Testing Frameworks in the Real World: A Practical Guide with Pytest

Why Do We Need API Testing Frameworks?

The Tooling: Python, Pytest, and Requests

Real-World Scenario: Testing a User Management API

Step 1: Setting up the environment

Step 2: Writing our first tests

Step 3: Running the tests

Advanced Real-World Practices

1. Data-Driven Testing with @pytest.mark.parametrize

2. Authentication and Setup with Pytest Fixtures

3. Schema Validation

Conclusion

Breaking the SQL Barrier: How to Build a Natural Language Database Assistant

What is Text-to-SQL?

The Tech Stack

How It Works Under the Hood

1. The Brains (Hugging Face API)

2. The Data Layer

3. Putting it together with Streamlit

Why This Matters

Under the Hood: How Bandit SAST Analyzes Your Python Code

Implementing SAST in Your Infrastructure: Detecting Vulnerabilities with Checkov and GitHub Actions

1.2 Optimized Data Caching with `@st.cache_data`

1. Data-Driven Testing with `@pytest.mark.parametrize`

1. Data-Driven Testing with `@pytest.mark.parametrize`

1. Data-Driven Testing with `@pytest.mark.parametrize`