DEV Community: Vittorio Banfi

ShowDev: CodeBeaver, open-source agent for testing

Vittorio Banfi — Tue, 11 Mar 2025 17:16:28 +0000

I just open-sourced CodeBeaver, a tool I built after LLM-generated code kept sneaking weird bugs into my projects.

With just a few lines of YAML, CodeBeaver can:

Run end-to-end (E2E) tests written in natural language
Generate, maintain, and execute unit tests automatically
Analyze test failures to determine if it’s a bug or just a flaky test

You can run it locally with a quick pip install, or integrate it into CI/CD with GitHub Actions, where it will even open PRs with missing tests.

It's basically vibe testing :D

We use BrowserUse for the E2E, O3-mini for the unit test generation, plus a bunch of shell scripts to make everything seamless.

Currently supports Python & TypeScript, with more languages on the roadmap. Would love to hear your thoughts!

You can check it out here on GitHub

Adding Unit Tests to Your Django Project with CodeBeaver - Tutorial

Vittorio Banfi — Mon, 17 Feb 2025 14:51:04 +0000

Your Django project is growing. More users, more features, more complexity. You know you need a proper testing strategy, but who has time to write hundreds of unit tests? Between shipping features and fixing bugs, testing often takes a back seat - until something breaks in production.

What if you could set up a complete testing infrastructure in minutes and have AI write and maintain your tests automatically?

This tutorial shows you exactly that. We'll take your existing Django project from zero to fully tested by:

Setting up a professional testing infrastructure using pytest-django (10 minutes)
Connecting your GitHub repository to CodeBeaver's AI testing pipeline (2 minutes)
Learning the LLM-powered workflow we use at CodeBeaver to ship features faster and with fewer bugs

By the end of this tutorial, you'll have:

A complete testing setup that automatically generates tests for new code
AI-powered test maintenance that keeps your test suite up-to-date as your code evolves
A modern development workflow that leverages LLMs to write better, more testable code

Best of all? The entire setup takes less than 15 minutes. Let's get started!

Prerequisites

Before we begin, make sure you have:

A Django project (existing or new)
Python 3.6+ installed (python --version to check)
pip installed (pip --version to verify)
A GitHub account (GitLab and Bitbucket also work)
Basic familiarity with Django and pip

Setting Up Your Django Project for Testing

Remember how Django's startproject command set up the foundation of your project? Setting up testing requires a similar foundation - a few key files and configurations that will make everything else smoother. Let's build this foundation step by step.

Required Files and Project Structure

In a typical Django project, your tests might live in a tests.py file within each app. While this works for small projects, as your codebase grows, you'll want a more organized structure. Here's what we recommend:

myproject/
├── manage.py
├── pyproject.toml      # New: Modern Python project configuration
├── pytest.ini         # New: pytest configuration
├── conftest.py       # New: Shared pytest fixtures
├── myproject/
│   ├── __init__.py
│   ├── settings.py
│   └── urls.py
└── myapp/
    ├── __init__.py
    ├── models.py
    ├── views.py
    ├── tests/        # Instead of tests.py, use a directory
    │   ├── __init__.py
    │   ├── test_models.py
    │   ├── test_views.py
    │   └── conftest.py  # App-specific fixtures
    └── factories/    # New: Factories for test data
        ├── __init__.py
        └── user_factory.py

This structure separates your tests by component (models, views, etc.) while keeping them close to the code they're testing. Think of it like organizing your kitchen - you want your spices near your cooking area, but still sorted by type.

Installing pytest-django and Friends

While Django's built-in test framework is good, pytest offers more powerful features. Let's install the tools we'll need:

pip install pytest-django pytest-cov factory-boy

Add these to your project's requirements. In the root of your repository add a requirements-test.txt file and add the following:

pytest-django>=4.5.2
pytest-cov>=4.1.0
factory-boy>=3.3.0
-r requirements.txt  # Inherit your main requirements

Think of these packages as your testing toolkit:

pytest-django: The power drill of Django testing
pytest-cov: Your coverage measuring tape
factory-boy: Your test data assembly line

Configuration: Making Everything Work Together

Let's set up pyproject.toml - think of this as your project's master configuration:

[tool.pytest.ini_options]
DJANGO_SETTINGS_MODULE = "myproject.settings"
python_files = ["test_*.py", "*_test.py"]
addopts = """
    --ds=myproject.settings
    --reuse-db
    --cov=.
    --cov-report=term-missing
    --cov-fail-under=80
"""

Now create conftest.py in your project root. This file will hold fixtures (reusable test components) that any test can use:

import pytest
from django.contrib.auth import get_user_model
from django.test import Client

@pytest.fixture
def client():
    """A Django test client instance."""
    return Client()

@pytest.fixture
def auth_client(client, django_user_model):
    """A Django test client logged in as a basic user."""
    user = django_user_model.objects.create_user(
        username='testuser',
        password='testpass123'
    )
    client.login(username='testuser', password='testpass123')
    return client

Setting Up Your Test Database

Django handles test databases automatically, but let's make them faster and more reliable. Add this to your test settings:

# settings/test.py
from .base import *  # Import your base settings

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': ':memory:',  # Use in-memory database for tests
    }
}

# Speed up password hashing
PASSWORD_HASHERS = [
    'django.contrib.auth.hashers.MD5PasswordHasher',
]

# Disable migrations for tests
class DisableMigrations:
    def __contains__(self, item):
        return True
    def __getitem__(self, item):
        return None

MIGRATION_MODULES = DisableMigrations()

Creating Your Test Files Manually (optional)

CodeBeaver will create test files for you, so you can skip this section if you want.

Some engineers like to write tests, and it can be a good idea to understand how to create them manually first. A workflow that we also see is that developers create one test file manually while developing the feature and then let CodeBeaver take over from there. In this case, CodeBeaver adds tests to cover edge cases. It will also maintain the test file as you change the code.

Let's say you have a simple Django model for blog posts. Here's how you'd structure its tests:

# myapp/tests/test_models.py
import pytest
from django.utils import timezone
from myapp.models import BlogPost

@pytest.mark.django_db
class TestBlogPost:
    def test_create_post(self):
        post = BlogPost.objects.create(
            title="Test Post",
            content="Test Content",
            published_at=timezone.now()
        )
        assert post.title == "Test Post"
        assert post.content == "Test Content"

    def test_post_str_representation(self):
        post = BlogPost.objects.create(
            title="Test Post",
            content="Test Content"
        )
        assert str(post) == "Test Post"

For views, you'll want separate test files:

# myapp/tests/test_views.py
import pytest
from django.urls import reverse

@pytest.mark.django_db
class TestBlogPostViews:
    def test_post_list_view(self, client):
        url = reverse('blog:post_list')
        response = client.get(url)
        assert response.status_code == 200

    def test_post_detail_view(self, client, blog_post):
        url = reverse('blog:post_detail', kwargs={'pk': blog_post.pk})
        response = client.get(url)
        assert response.status_code == 200
        assert blog_post.title in response.content.decode()

Using Factories for Test Data

Instead of creating test data manually in each test, use factories:

# myapp/factories/blog_factory.py
import factory
from django.utils import timezone
from myapp.models import BlogPost

class BlogPostFactory(factory.django.DjangoModelFactory):
    class Meta:
        model = BlogPost

    title = factory.Sequence(lambda n: f"Test Post {n}")
    content = factory.Faker('paragraph')
    published_at = factory.LazyFunction(timezone.now)
    author = factory.SubFactory('myapp.factories.UserFactory')

Now your tests become much cleaner:

def test_recent_posts(self):
    # Create 5 posts at once
    posts = BlogPostFactory.create_batch(5)
    recent_posts = BlogPost.objects.recent()
    assert len(recent_posts) == 5

This setup might seem like a lot, but it's like mise en place in cooking - having everything prepared makes the actual work much smoother. In the next section, we'll see how CodeBeaver can help maintain and expand your test suite automatically, working within this structure we've created.

Your First Test-Driven PR: Watching CodeBeaver in Action

Now that we have our testing infrastructure set up, let's see how CodeBeaver helps maintain your test suite. We'll walk through a real-world scenario: adding a new feature to track user engagement on blog posts.

Installing CodeBeaver

Now that we have our Python project structured and ready, let's integrate CodeBeaver into our workflow. This integration will transform your repository from having no test coverage to maintaining comprehensive test suites automatically. The process is straightforward and takes just a few minutes.

Step 1: Authentication and Authorization

First, navigate to codebeaver.ai and select "Sign up with GitHub". This initiates a secure OAuth flow that will allow CodeBeaver to interact with your repositories. If you're using GitLab or Bitbucket, you'll find similar options for those platforms.

After authenticating, you'll be prompted to authorize CodeBeaver's access to your repositories. You'll see an installation screen that allows you to choose between personal and organizational repositories, select specific repositories or grant access to all.

Click "Install CodeBeaver" to proceed. Don't worry about getting the permissions exactly right - you can always modify these settings later as your needs change.

Step 2: Repository Selection

Once authorized, you'll be presented with a dashboard showing your available repositories. This is where you'll select the repository we just created and enable CodeBeaver for it.

The repository selection interface presents a clear list of your repositories, with options to search and filter if you manage many projects. Select your Python risk calculator repository to proceed.

Step 3: Automatic Configuration

CodeBeaver will now analyze your repository structure to determine:

The programming language(s) in use
Testing frameworks present (pytest in our case)
Project structure and dependencies
Existing test configurations

Based on this analysis, CodeBeaver will attempt to auto-configure itself. For a standard Python project like ours that uses pytest, this process should complete successfully.

If auto-configuration succeeds, you'll see options for how you'd like to proceed with CodeBeaver. Select the Pull Request you just opened before. You are done! CodeBeaver will start working on your Pull Request.

What If Auto-Configuration Fails?

If you are using your own project, it may happen that CodeBeaver will not be able to auto-configure itself. Don't worry! This usually happens when:

Your project uses a non-standard structure
You have multiple testing frameworks
You need custom test commands

In these cases, you can:

Check the troubleshooting guide in the CodeBeaver documentation
Add a codebeaver.yml configuration file to your repository
Contact CodeBeaver support for assistance

With CodeBeaver installed and configured, you're ready to experience automated test generation in action. In the next section, we'll create our first pull request and watch as CodeBeaver automatically generates and maintains your tests.

Trying everything out

Everything is set up, so let's try it out!

Let's say we want to add a feature that tracks how many times each blog post is viewed. First, we'll modify our BlogPost model:

# blog/models.py
from django.db import models
from django.utils import timezone

class BlogPost(models.Model):
    title = models.CharField(max_length=200)
    content = models.TextField()
    author = models.ForeignKey('auth.User', on_delete=models.CASCADE)
    published_at = models.DateTimeField(default=timezone.now)
    view_count = models.PositiveIntegerField(default=0)  # New field

    def increment_views(self):
        """Increment the view count for this post."""
        # Using F() to avoid race conditions
        from django.db.models import F
        self.view_count = F('view_count') + 1
        self.save(update_fields=['view_count'])

    def get_engagement_score(self):
        """Calculate an engagement score based on views and age."""
        if not self.published_at:
            return 0

        age_in_days = (timezone.now() - self.published_at).days
        if age_in_days < 1:
            age_in_days = 1

        return round(self.view_count / age_in_days, 2)

And update our view to use this new functionality:

# blog/views.py
from django.views.generic import DetailView
from django.db import transaction
from .models import BlogPost

class BlogPostDetailView(DetailView):
    model = BlogPost
    template_name = 'blog/post_detail.html'

    def get_object(self, queryset=None):
        obj = super().get_object(queryset)
        with transaction.atomic():
            obj.increment_views()
        return obj

    def get_context_data(self, **kwargs):
        context = super().get_context_data(**kwargs)
        context['engagement_score'] = self.object.get_engagement_score()
        return context

Now, let's create a new branch and commit these changes:

git checkout -b feature/post-analytics
git add .
git commit -m "feat: add view tracking and engagement scoring to blog posts"

Now, we can open a pull request and watch CodeBeaver do its magic.

Opening the Pull Request

Create a new branch and commit these changes:

git checkout -b feature/post-analytics
git add blog/models.py blog/views.py
git commit -m "feat: add view tracking and engagement scoring to blog posts"
git push origin feature/post-analytics

Open a pull request on GitHub. You are done! CodeBeaver will start working on your Pull Request.

Understanding CodeBeaver's Analysis

When CodeBeaver analyzes your PR, it looks for several key aspects:

New or modified model fields (view_count)
Business logic methods (increment_views, get_engagement_score)
View modifications that affect database state
Potential race conditions
Edge cases in calculations

Within a few minutes, CodeBeaver will create a new PR with generated tests. You can check an example Pull Request here.

Best Practices and Tips: Making Your Django Code Test-Friendly

When writing testable code, many developers make the mistake of starting with implementation. The real breakthrough comes from starting with clear documentation and well-structured functions. In this section, we'll explore how to make your Django code not just testable, but a joy to test - focusing on powerful docstrings, clear function contracts, and code organization patterns that make testing natural and effective.

The Power of Docstrings: Your Testing Blueprint

Think of a docstring as a contract between you and future developers (including yourself!). But with CodeBeaver, it's more than that - it's your direct line of communication to the AI about what your code should do. Let's look at a poorly documented function and transform it into a testing-friendly version:

# Before: Hard to test, unclear expectations
def process_order(order, user):
    if user.is_active:
        order.status = 'processing'
        order.save()
        return True
    return False

# After: Clear expectations, easy to test
def process_order(order, user) -> bool:
    """
    Process a new order if the user is active.

    Args:
        order: Order instance to process
        user: User attempting to process the order

    Returns:
        bool: True if order was processed, False if user is inactive

    Raises:
        ValueError: If order is already processed
        TypeError: If order or user are incorrect types

    Example:
        >>> user = User.objects.create(is_active=True)
        >>> order = Order.objects.create(status='new')
        >>> process_order(order, user)
        True
        >>> order.status
        'processing'
    """
    if not isinstance(order, Order) or not isinstance(user, User):
        raise TypeError("Invalid order or user type")

    if order.status != 'new':
        raise ValueError(f"Cannot process order with status {order.status}")

    if not user.is_active:
        return False

    order.status = 'processing'
    order.save()
    return True

Let's break down why this docstring is so powerful for testing:

1. Input Documentation

Clear parameter descriptions
Type hints that CodeBeaver can validate
Explicit preconditions (order must be 'new')

2. Output Contract

Return value meaning is explicit
All possible outcomes are documented
Examples show expected behavior

3. Error Conditions

All exceptions are documented
Error scenarios are clearly defined
Edge cases are mentioned

Why Docstrings Matter More Than You Think

Here's a real example of how good docstrings saved my team time. We had a payment processing function:

def calculate_subscription_renewal(subscription, renewal_date=None):
    """
    Calculate the next renewal amount and date for a subscription.

    Args:
        subscription: Subscription model instance
        renewal_date: Optional date to calculate renewal for
                     Defaults to subscription.current_period_end

    Returns:
        tuple: (
            renewal_amount: Decimal - The amount to charge
            renewal_date: datetime - When the renewal takes effect
            currency: str - Three-letter currency code
        )

    Examples:
        Basic renewal:
        >>> sub = Subscription.objects.create(amount=100)
        >>> amount, date, currency = calculate_subscription_renewal(sub)
        >>> amount
        Decimal('100.00')

        Prorated renewal:
        >>> from datetime import timedelta
        >>> future = timezone.now() + timedelta(days=15)
        >>> amount, date, currency = calculate_subscription_renewal(sub, future)
        >>> amount < Decimal('100.00')
        True

    Raises:
        ValueError: If subscription is cancelled or renewal_date is in the past
        TypeError: If renewal_date is not None or datetime
    """

When CodeBeaver saw this docstring, it generated comprehensive tests that caught several edge cases:

Timezone handling around midnight
Proration calculations at month boundaries
Currency conversion edge cases
Invalid date validation

The examples in the docstring were particularly valuable - CodeBeaver used them as a starting point and then generated variations to test boundary conditions.

Example of a complete LLM workflow

Here's a workflow that has transformed how my team writes testable code. If you are using a GitHub Copilot, Cursor or VSCode Copilot, you can use it to help you write docstrings.

Simply, you start by writing the name of your def. Then you add a simple docstring with the purpose of the function, nothing else:

def process_order(order, user):
    """
    Process the order by matching the delivery address to the user's address. If the user has no address, we raise an error. If it takes more than 4 days, return that in the return object. otherwise the return object contains only the order
    """
    raise NotImplementedError("Not implemented yet")

I then select the def and ask the LLM to write a more detailed docstring, by defining return values and other details. For example, with Claude 3-5 I get:

def process_order(order, user):
    """
    Process an order by validating and matching delivery address with user's address.

    Args:
        order (Order): The order to be processed
        user (User): The user placing the order

    Returns:
        dict: Processing result containing:
            - 'order' (Order): The processed order object
            - 'processing_time' (int, optional): Number of days for delivery,
              only included if exceeds 4 days
            - 'status' (str): Processing status ('success' or 'delayed')

    Raises:
        ValueError: If user has no address configured
        TypeError: If order or user are not of correct type
        ValidationError: If order is already processed or invalid

    Examples:
        Standard processing:
        >>> user = User.objects.create(address="123 Main St")
        >>> order = Order.objects.create(status="pending")
        >>> result = process_order(order, user)
        >>> result
        {'order': <Order: #123>, 'status': 'success'}

        Delayed processing:
        >>> result = process_order(delayed_order, user)
        >>> result
        {
            'order': <Order: #124>,
            'status': 'delayed',
            'processing_time': 5
        }
    """
    raise NotImplementedError("Not implemented yet")

I now review the docstring and make edits if the LLM hallucinated something or got something wrong.

Once that's done, I just select the NotImplementedError and ask the LLM to implement the function. Et voilà! I have a working function that you can review. Not only that: Thanks to the detailed docstring, CodeBeaver will generate tests for you that cover all the possible cases after you push your changes:

git add .
git commit -m "feat: implement process_order"
git push origin feature/process-order

Now, I open a PR and CodeBeaver will start working on the PR.

Conclusion: Your Journey to Testing Excellence

You've come a long way from where we started! Remember that initial scenario - the Django developer pushing to production and hoping nothing breaks? That's no longer you. You've taken the first crucial steps toward building a robust, tested Django application. Let's reflect on your journey and plan your next steps.

What You've Learned

Think back to where we started. You now understand not just the mechanics of testing Django applications, but the deeper principles that make testing effective. You've learned how to structure your code with testing in mind, starting with those crucial docstrings that serve as both documentation and testing blueprints. You've seen how CodeBeaver can transform those docstrings into comprehensive test suites, catching edge cases you might never have thought about.

The most important shift isn't in the tools or configurations - it's in how you think about your code. You're no longer writing functions that merely work; you're crafting well-documented, testable components that prove they work. That's a fundamental transformation in how you approach software development.

Your Next Testing Adventures

Now that you have the foundation in place, here are some exciting directions to explore:

1. Expand Your Test Coverage Gradually

Start with your most critical paths - user authentication, payment processing, data mutations. CodeBeaver can help you identify these areas by analyzing your codebase. Remember, you don't need to test everything at once. Focus on:

# High-priority testing targets:
def process_payment(order):
    """This affects your bottom line - test it first!"""

# Medium priority:
def update_user_preferences(user, preferences):
    """Important but not critical - test after core functions"""

# Lower priority:
def get_user_avatar_url(user):
    """Nice to have tests, but not urgent"""

2. Enhance Your Testing Infrastructure

As your test suite grows, consider adding these powerful tools:

Factory Boy for more sophisticated test data generation
pytest-xdist for parallel test execution
pytest-cov for detailed coverage reporting

3. Build Testing into Your Workflow

Make testing as natural as writing code:

Write your docstring
Let your favorite LLM help implement the function
Push to GitHub
Let CodeBeaver generate and maintain your tests
Review and merge

The Path Forward

Remember that testing isn't a destination - it's a journey. Every test you add makes your application more reliable, every docstring makes your code more maintainable, and every PR becomes an opportunity to improve your test coverage.

Don't feel pressured to achieve 100% coverage immediately. Start with the most critical parts of your application and let your test suite grow organically. CodeBeaver will be there to help you maintain and expand your tests as your codebase evolves.

Additional Resources

To continue your testing journey:

Join our Discord community where you can share experiences and get help from other Django developers using CodeBeaver
Check out Django's testing documentation for deep dives into specific testing features
Explore pytest-django's documentation for advanced testing techniques
Review real-world examples in our GitHub repository

Final Thoughts

Testing might have seemed daunting when you started reading this tutorial, but look how far you've come! You now have the knowledge and tools to build reliable, well-tested Django applications. Remember, every great codebase started with a single test. Your journey to testing excellence is just beginning, and with CodeBeaver by your side, you're well-equipped for the road ahead.

Now, how about opening that first PR and letting CodeBeaver help you write some tests? Your future self (and your users) will thank you!

Setting Up Your First Python Unit Testing Pipeline with CodeBeaver - Tutorial

Vittorio Banfi — Fri, 14 Feb 2025 15:14:18 +0000

Ever found yourself pushing code at 2 AM, crossing your fingers, and hoping nothing breaks in production? We've all been there. But as AI accelerates our development speed, the "push and pray" approach isn't cutting it anymore. That's where automated testing comes in - and we're going to show you how to set it up in minutes.

This tutorial is perfect for Python developers who:

Know their way around Python but haven't tackled testing yet
Are shipping code faster than ever thanks to AI tools
Want to catch bugs before users do (and before that 2 AM emergency call)
Would rather spend time building features than manually writing test cases

We'll show you how to set up a complete testing pipeline powered by AI. CodeBeaver will automatically generate, run, and maintain your tests - think of it as having a testing expert on your team who never sleeps.

The best part? It's completely free for open source projects, and you can try it on private repos with our 14-day trial. No credit card required.

Ready to level up your Python development game? Let's dive in!

Getting Started

We're going to set up a complete Python testing workflow that will:

Automatically run tests whenever you push new code
Generate missing tests to maintain solid coverage
Help catch bugs before they reach production
Work naturally with your existing GitHub workflow

The best part? Once we set this up, it largely runs itself. No more hastily adding # TODO: add tests comments at midnight before a release.

Prerequisites

Before we dive in, make sure you have:

Python 3.6 or higher installed (run python --version to check)
pip installed and working (run pip --version to verify)
A GitHub account (also GitLab or Bitbucket will work)
Basic familiarity with Python and pip
A willingness to level up your development game

What's Coming Up

Think of this tutorial as your journey from "what's a test fixture?" to "look at my beautiful test coverage report!" We'll progress through several key stages:

First, we'll set up a basic Python project with proper structure - similar to how you'd set up a new virtual environment and requirements.txt, but optimized for testing.
Next, we'll introduce pytest - think of it as pip for testing. Just as pip manages your project's dependencies, pytest will manage your test execution.
Then, we'll connect CodeBeaver - your new AI testing assistant. Imagine having a senior developer who specializes in testing looking over your shoulder, but without the awkward coffee breath.
Finally, we'll create your first pull request and watch as CodeBeaver automatically generates tests for your code.

Understanding the Value of Testing in Python

Before we jump into the technical setup, let's talk about why testing matters specifically for Python projects. Unlike languages with static typing, Python's dynamic nature means we can't rely on the compiler to catch certain types of errors. Consider this seemingly innocent code:

def calculate_user_score(points, multiplier):
    return points * multiplier

# Works fine
result = calculate_user_score(100, 1.5)  # 150.0

# Uh oh...
result = calculate_user_score("100", 1.5)  # TypeError!

Without tests, this type of error might only surface when a user enters string input instead of a number - possibly weeks after deployment. Good unit tests catch these issues before they reach production, saving you from those dreaded 3 AM "production is down" messages.

Think of unit tests like the docstring checking feature in your IDE - they're there to catch problems early and document how your code should behave. Just as you wouldn't skip writing requirements.txt because managing dependencies manually is "faster," you shouldn't skip testing because writing features without tests feels quicker in the moment.

What Makes Python Testing Different?

Python's testing ecosystem has some unique advantages that make it particularly well-suited for automated testing:

Python's assert statement makes test assertions readable and natural
The pytest framework uses Python's introspection capabilities to make test discovery automatic
Python's dynamic nature means we can easily mock and patch objects for testing
The extensive use of duck typing in Python makes it crucial to test behavior rather than just types

In the next section, we'll start setting up our Python project with these advantages in mind. We'll create a structure that makes testing as natural as importing a module, and then we'll let CodeBeaver handle the heavy lifting of actually writing those tests.

Remember: Just as pip revolutionized Python package management (remember the days of manually downloading and installing packages?), tools like CodeBeaver are revolutionizing how we approach testing. Ready to join the testing revolution? Let's dive into the setup in the next section!

Setting Up Your Python Project for Testing

Remember how switching from pip install commands to using a requirements.txt file made your Python projects more organized and reproducible? We're about to do something similar for testing. Just as a well-structured requirements file makes dependency management smoother, a well-organized testing structure makes writing and maintaining tests much easier.

Creating Your Python Project Structure

Let's start with a project structure that separates our application code from our tests. While you might be used to seeing Python projects with just a src directory and requirements file, a test-friendly structure includes a few additional elements. Here's what we'll create:

my_project/
├── src/
│   ├── my_project/
│   │   ├── __init__.py
│   │   ├── core.py
│   │   └── utils.py
│   └── setup.py
├── tests/
│   ├── __init__.py
│   ├── test_core.py
│   └── test_utils.py
├── requirements.txt
├── requirements-test.txt
├── pytest.ini
└── .gitignore

Let's create this structure step by step. First, make your project directory and navigate into it:

mkdir my_project
cd my_project

Now, let's set up a virtual environment - this is probably familiar territory for you:

python -m venv venv
source venv/bin/activate  # On Windows, use: venv\Scripts\activate

Understanding the Two-Requirements Approach

You might be wondering why we have both requirements.txt and requirements-test.txt. This separation follows a important principle in software development: keeping production dependencies separate from development dependencies. Here's why this matters:

# requirements.txt - Production dependencies
pandas==2.0.0
requests==2.28.2
python-dotenv==1.0.0

# requirements-test.txt - Testing dependencies
pytest==7.3.1
pytest-cov==4.0.0
pytest-mock==3.10.0
-r requirements.txt  # This line inherits production dependencies

Think of it this way: when your code runs in production, it doesn't need testing libraries. Just as you wouldn't include your development IDE in your production environment, you don't need testing tools there either. This separation also makes your deployment pipelines faster and more secure.

Setting Up pytest

Now, let's create a pytest.ini file. This is similar to how setup.cfg configures your Python package behavior - it tells pytest how to run your tests:

[pytest]
testpaths = tests
python_files = test_*.py
addopts =
    --cov=src/my_project
    --cov-report=term-missing
    --cov-fail-under=80
markers =
    slow: marks tests as slow (deselect with '-m "not slow"')
    integration: marks tests as integration tests

Let's break down what each of these settings does:

testpaths = tests tells pytest where to look for test files
python_files = test_*.py defines the naming pattern for test files
addopts configures default command-line options:
- --cov=src/my_project measures code coverage for your project
- --cov-report=term-missing shows which lines aren't tested
- --cov-fail-under=80 ensures at least 80% code coverage
markers lets you categorize tests (similar to how you might tag functions with decorators)

Adding Some Initial Code to Test

Let's add a simple Python module that we'll use as an example. Create src/my_project/utils.py:

def calculate_risk_score(income: float, credit_score: int, debt_ratio: float) -> float:
    """
    Calculate a risk score for a loan application.

    Args:
        income: Annual income in dollars
        credit_score: Credit score (300-850)
        debt_ratio: Monthly debt payments / monthly income

    Returns:
        risk_score: Score between 0 (highest risk) and 100 (lowest risk)
    """
    if not 300 <= credit_score <= 850:
        raise ValueError("Credit score must be between 300 and 850")

    if debt_ratio < 0 or debt_ratio > 1:
        raise ValueError("Debt ratio must be between 0 and 1")

    if income <= 0:
        raise ValueError("Income must be positive")

    # Base score from credit score (40% weight)
    credit_score_component = ((credit_score - 300) / 550) * 40

    # Income component (30% weight)
    income_component = min(income / 100000, 1) * 30

    # Debt ratio component (30% weight)
    debt_component = (1 - debt_ratio) * 30

    return credit_score_component + income_component + debt_component

This function might look simple, but it has several aspects that need testing:

Input validation for each parameter
Edge cases (minimum and maximum values)
The business logic of the scoring algorithm
Error handling

Without proper testing, we might miss edge cases like what happens when someone enters negative income or a credit score of 900. This is exactly the kind of code where CodeBeaver shines - it can identify these edge cases automatically.

Running pytest

Now that we have our project structure set up, let's run pytest to see where we stand with our testing. This step is important because it establishes our baseline and helps us understand what CodeBeaver will be working with.

First, let's install our testing dependencies. Create a requirements-test.txt file with these contents:

pytest==7.3.1
pytest-cov==4.0.0
pytest-mock==3.10.0
-r requirements.txt

Then install these dependencies:

pip install -r requirements-test.txt

Now, let's run pytest for the first time:

python -m pytest

You'll see output that looks something like this:

============================= test session starts ==============================
platform linux -- Python 3.9.7, pytest-7.3.1, pluggy-1.0.0
rootdir: /path/to/my_project, configfile: pytest.ini
plugins: cov-4.0.0, mock-3.10.0
collected 0 items

============================ no tests ran in 0.12s ============================

Don't worry about the "no tests ran" message – this is exactly what we expect! Remember, we haven't written any tests yet. This is where CodeBeaver will come in handy.

Let's also try running pytest with coverage reporting enabled:

python -m pytest --cov=src/my_project

You'll see additional output showing our current coverage:

============================= test session starts ==============================
platform linux -- Python 3.9.7, pytest-7.3.1, pluggy-1.0.0
rootdir: /path/to/my_project, configfile: pytest.ini
plugins: cov-4.0.0, mock-3.10.0
collected 0 items

---------- coverage: platform linux, python 3.9.7-final-0 -----------
Name                                      Stmts   Miss  Cover
-------------------------------------------------------------
src/my_project/utils.py                      20     20     0%
-------------------------------------------------------------
TOTAL                                        20     20     0%

============================ no tests ran in 0.12s ============================

This output tells us several important things:

Our project structure is correct (pytest found our code)
We have 0% test coverage (all 20 statements in utils.py are untested)
The testing environment is properly configured

This is exactly the situation where CodeBeaver shines. Rather than writing all these tests manually, we'll let CodeBeaver analyze our code and generate comprehensive tests that cover all these untested statements. In the next section, we'll push our code to GitHub and set up CodeBeaver to start generating these tests automatically.

The structure we've created gives CodeBeaver everything it needs to understand our code and generate meaningful tests:

A clear project structure that follows Python best practices
Well-documented functions with type hints and docstrings
Properly configured testing tools (pytest and coverage reporting)
A baseline coverage report showing what needs to be tested

With this foundation in place, we're ready to move on to setting up our GitHub repository and connecting CodeBeaver. This is where the magic begins – transforming our untested code into a well-tested, production-ready project.

Pushing a Pull Request on Github

Before we move on to installing CodeBeaver, let's create a .gitignore file to keep our repository clean. You can copy this one from GitHub. Add it to the root of your proejct.

(Optional) Create a New Repository on GitHub

This section applies only if you don't have a GitHub repository yet for this project. You can skip to the next chapter if you already have a repository.

Log into your GitHub account and click the "+" icon in the top right, then select "New repository"
Name your repository "python-risk-calculator" (or another name that describes your project)
Add a description like "A Python library for calculating financial risk scores"
Choose "Public" if you want to use CodeBeaver's free tier for open source projects, or "Private" if you're using the trial/paid version
Don't initialize with a README since we already have our local project
Click "Create repository"

GitHub will show you commands to push your existing repository. Don't copy them just yet - we'll use our own sequence of commands.

Initialize Git and Push Your Code

First, initialize Git in your project directory and create your initial commit:

# Make sure you're in your project root directory
cd my_project

# Initialize git
git init

# Add all files
git add .

# Create initial commit
git commit -m "feat: initial project setup with risk calculator"

Now, connect your local repository to GitHub and push your code:

# Add the remote repository (replace with your repository URL)
git remote add origin https://github.com/yourusername/python-risk-calculator.git

# Push your code to main branch
git push -u origin main

Create a Feature Branch

Following Git best practices, let's create a feature branch for our risk calculator implementation:

# Create and checkout a new branch
git checkout -b feat/risk-calculator-implementation

Now that we are in a feature branch, let's update our utils.py to include a new helper function:

def validate_loan_parameters(loan_amount: float, loan_term_years: int) -> None:
    """
    Validate basic loan parameters.

    Args:
        loan_amount: The requested loan amount in dollars
        loan_term_years: The loan term in years

    Raises:
        ValueError: If parameters are invalid
    """
    if loan_amount <= 0:
        raise ValueError("Loan amount must be positive")
    if not 1 <= loan_term_years <= 30:
        raise ValueError("Loan term must be between 1 and 30 years")

These changes add some functionality to our risk calculator. Let's commit the changes and push them to GitHub!

# Commit the changes
git add .
git commit -m "feat: add risk calculator implementation"

# Push the branch to GitHub
git push -u origin feat/risk-calculator-implementation

Open Your Pull Request

Now that we have a feature branch pushed to GitHub, we can open a Pull Request. A Pull Request is, in brief, a way to propose changes to a repository.
To open one:

Visit your repository on GitHub
You should see a banner saying "feat/risk-calculator-implementation had recent pushes" with a "Compare & pull request" button
Click the "Compare & pull request" button
Fill in your pull request description.
Click "Create pull request"

Now your code is ready for CodeBeaver to analyze and generate tests! The pull request we've created follows several best practices:

It's focused on a single feature
It has a clear description of what's being implemented
It mentions testing expectations
It's based on well-documented code (thanks to our detailed docstrings)

These practices help CodeBeaver generate more relevant and comprehensive tests for your code. In the next section, we'll see how to install CodeBeaver and watch it work its magic on this pull request.

Installing CodeBeaver

Step 1: Authentication and Authorization

Click "Install CodeBeaver" to proceed. Don't worry about getting the permissions exactly right - you can always modify these settings later as your needs change.

Step 2: Repository Selection

Once authorized, you'll be presented with a dashboard showing your available repositories. This is where you'll select the repository we just created and enable CodeBeaver for it.

The repository selection interface presents a clear list of your repositories, with options to search and filter if you manage many projects. Select your Python risk calculator repository to proceed.

Step 3: Automatic Configuration

CodeBeaver will now analyze your repository structure to determine:

The programming language(s) in use
Testing frameworks present (pytest in our case)
Project structure and dependencies
Existing test configurations

Based on this analysis, CodeBeaver will attempt to auto-configure itself. For a standard Python project like ours that uses pytest, this process should complete successfully.

What If Auto-Configuration Fails?

If you are using your own project, it may happen that CodeBeaver will not be able to auto-configure itself. Don't worry! This usually happens when:

Your project uses a non-standard structure
You have multiple testing frameworks
You need custom test commands

In these cases, you can:

Check the troubleshooting guide in the CodeBeaver documentation
Add a codebeaver.yml configuration file to your repository
Contact CodeBeaver support for assistance

Your First Test-Driven Pull Request

In around 5 minutes, CodeBeaver will add a comment to your Pull Request. It will look something like this:

If you click on the Pull Request link in the comment you will go to the Pull Request opened by CodeBeaver. You will notice that it’s a Pull Request opened on top of your original Pull Request:

To review the files, you can check out the diff in GitHub (same as any other Pull Request). Click on “Files Changed”

You can now review the code that CodeBeaver wrote for you.

Once you are ready, you can merge the Pull Request opened by CodeBeaver by clicking on the “Merge pull request”

Working with CodeBeaver: Best Practices

Just as following PEP 8 makes your Python code more maintainable, following certain practices with CodeBeaver will help you get the most out of automated testing. Let's explore some key strategies that will help CodeBeaver generate more accurate and comprehensive tests for your Python code.

Documentation is Your Testing Superpower

Remember how helpful a well-written docstring is when you're trying to understand someone else's code? For CodeBeaver, good documentation is even more crucial. Here's why:

# Less helpful for CodeBeaver:
def calculate_tax(amount, rate):
    return amount * rate

# Much better for CodeBeaver:
def calculate_tax(amount: float, rate: float) -> float:
    """
    Calculate tax amount based on a given rate.

    Args:
        amount: Base amount in dollars (must be positive)
        rate: Tax rate as decimal (e.g., 0.07 for 7%)

    Returns:
        float: Calculated tax amount

    Examples:
        >>> calculate_tax(100.0, 0.07)
        7.0

    Raises:
        ValueError: If amount is negative or rate is not between 0 and 1
    """
    if amount < 0:
        raise ValueError("Amount must be positive")
    if not 0 <= rate <= 1:
        raise ValueError("Rate must be between 0 and 1")
    return amount * rate

The second version gives CodeBeaver crucial information about:

Expected input types and ranges
Example usage and expected outputs
Error conditions that should be tested
Business rules (like valid ranges for tax rates)

Leveraging Real-World Data in Tests

When you have access to real-world data that represents actual use cases, you can help CodeBeaver generate more realistic tests. There are two effective ways to do this:

Include examples in your docstrings:

def validate_user_input(age: int, email: str) -> bool:
    """
    Validate user registration data.

    Args:
        age: User's age in years
        email: User's email address

    Example Data:
        Valid cases:
        - age=25, email="user@example.com"
        - age=18, email="student.2024@university.edu"

        Invalid cases:
        - age=12, email="tooyoung@example.com"  # Age below minimum
        - age=25, email="not-an-email"  # Invalid email format
    """

Create a separate test data file:

# tests/test_data/sample_users.py
SAMPLE_USERS = [
    {
        "age": 25,
        "email": "john.doe@example.com",
        "expected_valid": True
    },
    {
        "age": 15,
        "email": "invalid@test",
        "expected_valid": False
    }
]

Managing the Testing Workflow

Think of CodeBeaver as a meticulous code reviewer who specializes in testing. Here's how to make the most of this collaboration:

Review Generated Tests First Before merging your feature PR, always review and merge CodeBeaver's test PR first. This ensures that:

Your code is thoroughly tested before reaching production
You can catch any misunderstandings about the intended behavior
You might discover edge cases you hadn't considered

Iterative Testing If CodeBeaver's initial tests reveal gaps or misunderstandings:
- Update your docstrings to clarify the expected behavior
- Add more examples or edge cases to the documentation
- Push these changes and let CodeBeaver generate updated tests

Special Considerations for Large Codebases

When installing CodeBeaver in an existing large Python project, consider this gradual approach:

Start with New Code

Initially configure CodeBeaver to focus on new PRs and modified files
This prevents overwhelming reviews with massive test PRs

Incremental Coverage

Gradually expand coverage by adding tests for existing code
Focus on critical paths and high-risk areas first
Use CodeBeaver's file-specific testing feature for targeted improvements

Documentation Updates
- Systematically improve docstrings in existing code
- Prioritize modules that will need tests soon
- Include real-world examples from your production system

Remember: Just as you wouldn't push to production without reviewing your code, always review CodeBeaver's generated tests. They're not just a safety net – they're documentation of your code's intended behavior and edge cases.

By following these practices, you'll create a virtuous cycle: better documentation leads to better tests, which lead to more reliable code, which makes future development faster and safer. It's like compound interest for your codebase's quality!

Looking Forward

As your test suite grows, consider setting up test coverage goals in your pytest.ini file:

[pytest]
addopts =
    --cov=src/my_project
    --cov-report=term-missing
    --cov-fail-under=90  # Gradually increase this as coverage improves
markers =
    api: marks tests that require API access
    integration: marks integration tests

This gives your team clear targets while letting CodeBeaver help you reach them systematically and efficiently.

Remember: The goal isn't just to have tests – it's to have meaningful tests that catch real issues and document your code's behavior. With these practices and CodeBeaver's help, you're well on your way to achieving both!

Conclusion

Congratulations! You've just transformed your Python project from "we'll add tests someday" to "fully tested and ready for production." Just as virtual environments revolutionized Python development by making dependency management painless, CodeBeaver is changing how we approach testing by making it automatic and maintainable.

Throughout this tutorial, we've seen how combining good Python practices with AI-powered testing can create a robust development workflow. We started with a basic Python project structure, added proper documentation, and let CodeBeaver handle the heavy lifting of test creation and maintenance. The result? A testing pipeline that catches bugs before they reach production, without requiring you to become a testing expert overnight.

The real power here isn't just in having tests – it's in having a sustainable, scalable way to maintain test coverage as your codebase grows. Just as Git tracks your code changes, CodeBeaver now tracks your testing needs, automatically updating and expanding your test suite with each pull request.

Want to explore more automated testing approaches? Check out our React testing tutorial, which shows how to set up a similar pipeline for frontend development. Whether you're working with Python, JavaScript, or both, CodeBeaver has you covered.

Remember: Good tests aren't just a safety net – they're documentation, quality control, and peace of mind all rolled into one. With CodeBeaver watching your back, you can focus on what you do best: building great software.

Happy coding, and may all your tests be green! 🚀

Setting up your first frontend Unit Tests workflow with GitHub + React + CodeBeaver

Vittorio Banfi — Wed, 12 Feb 2025 07:57:33 +0000

Let’s face it – unit testing in frontend development often feels like trying to nail jelly to a wall. Many frontend developers have traditionally focused on crafting pixel-perfect UIs and smooth user experiences, leaving testing as that thing we’ll “definitely get to next sprint” 😅

But here’s the truth: solid unit testing isn’t just a nice-to-have anymore – it’s becoming as essential as that morning coffee ritual that powers our debugging sessions. In this tutorial, we’re going to transform your React project from “yeah, we should probably write tests someday” to having a professional, automated testing workflow that would make your backend colleagues jealous. To do so we will use CodeBeaver, the AI agent for Unit Tests.

Getting started

Before we dive into the technical setup, let’s address the elephant in the room: frontend testing has historically been… complicated. Between component lifecycles, state management, and asynchronous operations, there’s a lot to consider. But that’s exactly why having automated tools like CodeBeaver in your arsenal is a game-changer.

On average, engineering teams save 30 minutes per developer per day thanks to CodeBeaver. That’s not just coffee-break time – that’s significant bandwidth you can redirect toward building features that actually matter to your users.

What We’ll Build

We’re setting up a complete unit testing workflow that will:

Automatically run tests on every pull request
Generate missing tests to maintain 90% coverage
Help identify and fix bugs before they hit production
Integrate seamlessly with your GitHub workflow

The best part? Once we set this up, it practically runs itself. No more “I forgot to write tests” commits at 4:59 PM on a Friday.

Prerequisites

Before we start, make sure you have:

A GitHub account
Basic familiarity with git commands
Node.js installed on your machine
A desire to write better code (check ✅)

What’s Coming Up

In the following sections, we’ll:

Set up your repository with the right testing infrastructure
Configure CodeBeaver to automate your testing workflow
Create your first test-driven PR
Review and merge automatically generated tests

Think of this as your “testing zero to hero” journey. By the end, you’ll have a professional-grade testing setup that makes maintaining test coverage as natural as running npm start.

Setting Up Your React (or NextJS) project for testing

Alright, fellow code wranglers, let’s set up our repository to be test-friendly. Think of this as Marie Kondo-ing your codebase, but instead of asking “does it spark joy?” we’re asking “will this make our tests cry?” 😅

Creating Your GitHub Repository

If you’re starting from scratch, head over to GitHub and create a new repository. Here’s the TL;DR version:

Click that shiny “New repository” button
Name it something clever (but professional – sorry, definitely-not-another-todo-app will have to wait)
Initialize with a README because we’re not savages
Choose the Node .gitignore template – trust me, your node_modules folder thanks you
Setting Up Your Package.json for Testing Glory

Time to beef up your package.json with some testing superpowers. Here’s a complete package.json as an example:

{
  "name": "your-awesome-project",
  "version": "1.0.0",
  "scripts": {
    "test": "jest",
    "test:coverage": "jest --coverage",
  },
  "jest": {
    "testEnvironment": "jsdom",
    "setupFilesAfterEnv": [
      "<rootDir>/src/setupTests.ts"
    ],
    "moduleNameMapper": {
      "\\.(css|less|scss|sass)$": "identity-obj-proxy",
      "^@/(.*)$": "<rootDir>/src/$1"
    },
    "collectCoverageFrom": [
      "src/**/*.{js,jsx,ts,tsx}",
      "!src/**/*.d.ts",
      "!src/index.tsx",
      "!src/reportWebVitals.ts"
    ],
    "coverageThreshold": {
      "global": {
        "branches": 80,
        "functions": 80,
        "lines": 80,
        "statements": 80
      }
    }
  },
  "devDependencies": {
    "@testing-library/jest-dom": "^5.16.5",
    "@testing-library/react": "^13.4.0",
    "@testing-library/user-event": "^14.4.3",
    "jest": "^29.3.1",
    "jest-environment-jsdom": "^29.3.1",
    "identity-obj-proxy": "^3.0.0"
  }
}

If you already have a project, your package.json may look a lot different, and you may need to update it. To make updating easier, let’s break down the important sections of the JSON above.

"scripts": {
  "test": "jest",
  "test:coverage": "jest --coverage",
},

This is important as it declares how to test your code. As you see, for this tutorial we are using Jest.

After that, you can find some Jest own settings. You can remove them or not have them altogether, but they are useful in setting up how you want Jest to test your code:

"jest": {
    "testEnvironment": "jsdom",
    "setupFilesAfterEnv": [
      "<rootDir>/src/setupTests.js"
    ],
    "moduleNameMapper": {
      "\\.(css|less|scss|sass)$": "identity-obj-proxy",
      "^@/(.*)$": "<rootDir>/src/$1"
    },
    "collectCoverageFrom": [
      "src/**/*.{js,jsx,ts,tsx}",
      "!src/**/*.d.ts",
      "!src/index.tsx",
    ],
    "coverageThreshold": {
      "global": {
        "branches": 80,
        "functions": 80,
        "lines": 80,
        "statements": 80
      }
    }
  }

Woha this a lot! Let’s break down this Jest configuration like we’re reviewing a PR at 4:55 PM on a Friday (but with actual attention to detail 😉).

"testEnvironment": "jsdom"

First up, we’re telling Jest to use jsdom – think of it as a browser simulator for your Node environment. Without this, your DOM-related tests would throw more tantrums than a project manager during sprint planning.

"setupFilesAfterEnv": ["<rootDir>/src/setupTests.ts"]

This is where you put your test setup code that runs before your test suite kicks off. Perfect for importing @testing-library/jest-dom and setting up those sweet custom matchers. It’s like the pre-workout routine for your tests! 💪

"moduleNameMapper": {
  "\\.(css|less|scss|sass)$": "identity-obj-proxy",
  "^@/(.*)$": "<rootDir>/src/$1"
}

Here’s where we handle those pesky imports that Jest would otherwise get stuck on:

The first line handles your style imports (because let’s face it, Jest doesn’t care about your CSS-in-JS prowess)
The second line maps your fancy @/components absolute imports to their actual locations. No more ../../../ nonsense!

"collectCoverageFrom": [
  "src/**/*.{js,jsx,ts,tsx}",
  "!src/**/*.d.ts",
  "!src/index.tsx",
]

This tells Jest which files to include in coverage reports. Notice those ! patterns? That’s us saying “hey, let’s not waste time testing TypeScript declaration files and boilerplate code.” Because life’s too short to test index.tsx.

"coverageThreshold": {
  "global": {
    "branches": 80,
    "functions": 80,
    "lines": 80,
    "statements": 80
  }
}

The money maker! 🎯 This sets the bar at 80% coverage across all metrics. It’s like setting a high score for your codebase – miss these thresholds, and your CI pipeline will give you the same look your tech lead gives you when you push directly to main.

In essence, this configuration turns Jest from a simple test runner into a sophisticated testing powerhouse that would make even your backend colleagues nod in approval. And with CodeBeaver watching your back, maintaining these coverage thresholds becomes less of a chore and more of an automated victory lap! 🏃‍♂️🏆

File Structure

There are a lot of ways of organizing your test files, depending on the language and framework in which you are writing your code. In this case, since we are writing a Typescript and React project, my folder structure will be something like this:

src/
├── components/
│   ├── Button/
│   │   ├── Button.tsx
│   │   ├── Button.test.tsx
│   │   └── index.ts
│   └── Dropdown/
│       ├── Dropdown.tsx
│       ├── Dropdown.test.tsx
│       └── index.ts
├── utils/
│   ├── formatters.ts
│   └── formatters.test.ts
└── setupTests.ts

In this case, I’m keeping my test files right next to their implementation. It’s like keeping your coffee cup next to your keyboard – it just makes sense!

Adding some components (Optional)

Note: Do this step only if you are starting from an empty project!

Let’s add a main page and some components to get it started. I open-sourced a repository to get you started. My suggestion is to copy/paste some files into your project. It’s a great way to gain familiarity with the structure above.

Add Button.tsx in src/components/Button
Add Button.test.tsx in src/components/Button
Add Dropdown.tsx in src/componenets/Dropdown

You can of course check how I set up my repository here on this Pull Request. Feel free to copy any file to your project!

The GitHub PR Template (Optional)

You don’t actually need this, but it’s super useful. It adds a template to the Pull Request, so that every time you add a new Pull Request, its description will start from the template itself. This way, all of your Pull Request’s descriptions will contain a similar structure.

To add the template, open your text editor and add a file at this path: .github/pull_request_template.md

You can now add any markdown, for example:

## 🎯 What does this PR do?

<!-- Quick bullet points about the changes -->

## 🧪 Testing Instructions

<!-- How can reviewers test your changes? -->

## 📸 Screenshots (if applicable)

<!-- Drop some visual goodness here -->

## ✅ Checklist

- [ ] Tests added/updated
- [ ] Documentation updated
- [ ] CodeBeaver checks passed
- [ ] No coffee was harmed in the making of this PR

For more info, check out the GitHub documentation on this topic.

Monorepo or subfolder examples (optional)

If your project is a monorepo, or if your React project is not on the root, you will also need a codebeaver.yml configuration file. For example, let’s say that your repository has the react project in projects/react.

You will add a new file in the root of your repository called codebeaver.yml. It’s a YAML file that tells CodeBeaver where your React project is. This will work also with NextJS. This is how it looks like:

workspaces:
  - path: projects/react
    name: frontend
    from: jest

You will need to replace projects/react with the path of your React project relative to the root of your repository. You can check the full documentation on the codebeaver.yml file if you want more information about it.

The Final Boss: Push to Main

Now that we have everything, time to commit these changes to main:

git add .
git commit -m "chore: add testing infrastructure (and hopes and dreams) 🚀"
git push origin main

And there you have it! Your repository is now ready to embrace tests like a Java developer embraces design patterns. In the next section, we’ll connect CodeBeaver and watch it work its magic.

Remember: The best code is tested code, and the second-best code is the one that passes the tests we forgot to write. But with CodeBeaver, we won’t have to worry about the latter! 😉

Installing CodeBeaver: Where the Magic Gets Real 🪄

Alright, let’s get CodeBeaver installed and running. This is where your repository transforms from “tests? what tests?” to “look at my beautiful test coverage” in less time than it takes to explain why we need semantic versioning to product managers.

Step 1: The Grand Login 🔐

Head over to the login page codebeaver.ai and look for those magical words: “Sign up with GitHub”. Click that faster than you click “Mark All as Read” in your work email. You can also use CodeBeaver with GitLab or Bitbucket!

Great! Now CodeBeaver needs to access your GitHub repository in order to start writing tests. You will see a screen like this:

Click on Install CodeBeaver. You can give CodeBeaver access to the repositories of a GitHub organization you have access to, or to your personal Repositories. You can choose some repositories only or some of them. Don’t worry, you can add or remove repositories later at any time.

Step 2: Repository Selection 🎯

Now you can select the Repository you want to activate CodeBeaver for. The screen will look like this (this is mine, I have a lot of repos!)

As before, you will be able to change this selection later, so don’t worry. For the sake of this tutorial, pick the repository we created!

Step 3: CodeBeaver auto-configures itself 👽

Once you’ve added your repository, CodeBeaver will start analyzing your codebase and see if it can auto-configure itself. If you started from a blank project or if you added a codebeaver.yml file, the autoconfiguration should run smoothly and you will be ready to go. If it did not end up configuring itself, don’t worry! Check out the last chapter to see what to do from there.

Otherwise, you will see something like this:

Pick the option you prefer to try out CodeBeaver.

The “It’s Working!” Moment 🎉

Alright fellow code warriors, we’ve set up our testing infrastructure and got CodeBeaver watching our repository like a QA engineer after their fifth espresso. Now comes the fun part – let’s see this automation ballet in action!

Creating Your First Feature Branch 🌿

First, let’s create a branch that would make our git history proud:

# Create and checkout your feature branch
git checkout -b feat/add-user-avatar-component

Let’s add a simple Avatar component that we’ll intentionally leave untested (don’t worry, CodeBeaver’s got our back!):

// src/components/Avatar/Avatar.tsx
import React from 'react';

interface AvatarProps {
  imageUrl: string;
  alt: string;
  size?: 'sm' | 'md' | 'lg';
  status?: 'online' | 'offline' | 'away';
}

export const Avatar: React.FC<AvatarProps> = ({
  imageUrl,
  alt,
  size = 'md',
  status
}) => {
  const dimensions = {
    sm: 'h-8 w-8',
    md: 'h-12 w-12',
    lg: 'h-16 w-16'
  }[size];

  return (
    <div className="relative inline-block">
      <img 
        src={imageUrl}
        alt={alt}
        className={`${dimensions} rounded-full object-cover`}
      />
      {status && (
        <span 
          className={`absolute bottom-0 right-0 h-3 w-3 rounded-full border-2 border-white
            ${status === 'online' ? 'bg-green-500' : 
              status === 'away' ? 'bg-yellow-500' : 'bg-gray-500'
            }`}
        />
      )}
    </div>
  );
};

Now, let’s commit this beauty:

git add .
git commit -m "feat(components): add Avatar component with status indicator"
git push origin feat/add-user-avatar-component

Watching CodeBeaver Do Its Thing

Head over to your GitHub repository. You will see a dialog to create a new Pull Request. Go ahead and create a Pull Request. If you added a Pull Request template, you will see that as well! Once you click on “Create Pull Request”, here’s where the magic starts happening. You will see CodeBeaver working like this in GitHub:

CodeBeaver working on your GitHub Pull Request - Screenshot
What will happen is:

CodeBeaver will detect your new PR
It’ll notice there’s no test file for our Avatar component (tsk tsk!)
Start analyzing the component’s props, behavior, and edge cases
Generate comprehensive tests that would make TDD purists weep with joy

Reviewing the Generated Tests 🔍

CodeBeaver will add a comment to your Pull Request. It will look something like this:

If you click on the Pull Request link in the comment you will go to the Pull Request opened by CodeBeaver. You will notice that it’s a Pull Request opened on top of your original Pull Request:

To review the files, you can check out the diff in GitHub (same as any other Pull Request). Click on “Files Changed”

You can now review the code that CodeBeaver wrote for you.

Once you are ready, you can merge the Pull Request opened by CodeBeaver by clicking on the “Merge pull request”

Conclusion

Well, fellow code warriors, we’ve come a long way from “we should probably write some tests” to having a fully automated testing workflow that would make even the most zealous TDD advocate nod in approval. Let’s take a victory lap and see what we’ve accomplished! 🏃‍♂️

What We Built Together 🏗️

We didn’t just set up tests – we established a complete testing ecosystem that:

Transforms your React codebase from test-optional to test-mandatory (in the best possible way)
Automates the tedious parts of testing (because life’s too short to write edge cases at 4:59 PM)
Integrates seamlessly with your GitHub workflow (like a well-configured git hooks, but actually useful)

The Real MVP: Your Future Self 🦸‍♂️

Remember that feeling of dread when you had to modify a component and all its tests started failing faster than a junior dev’s first production deploy? Well, those days are now officially in your git history. With CodeBeaver watching your back:

Your tests evolve with your code (no more “it worked on my machine” moments)
Coverage stays high without manual intervention (like your coffee intake, but automated)
Bugs get caught before they can make it to production (and before your PM can schedule an emergency meeting)

The Path Forward 🛣️

Remember: CodeBeaver isn’t just a test writer – it’s your partner in maintaining code quality. When tests fail, it’ll help you:

Identify if it’s a bug in your new code (before your code reviewer does). Check out an example here.
Determine if existing tests need updates (because your awesome new feature changed the game). Check out an example here.
Maintain that sweet, sweet test coverage without breaking a sweat

The Bottom Line 💯

We’ve transformed your React project from “tests are optional” to “tests are automatic” – and did it without sacrificing your development velocity or your sanity. That’s not just a win; that’s a paradigm shift in how we approach frontend testing.

Remember: The best code isn’t just the code that works – it’s the code that proves it works through comprehensive tests. And now, thanks to CodeBeaver, you can have both without doubling your coffee budget! ☕

Happy coding, and may your tests be ever green! 🚀

P.S. If your team starts wondering how you became a testing guru overnight, just wink and let them think it’s all those extra hours you’ve been putting in (instead of CodeBeaver doing the heavy lifting) 😉

[I just published a complete tutorial on how to set up your first frontend Unit Testing workflow! ](https://www.codebeaver.ai/blog/tutorials/frontend-unit-tests-with-github-react-codebeaver/)

Vittorio Banfi — Wed, 12 Feb 2025 07:31:56 +0000

Unit Testing Without Tears: How CodeBeaver Turned Testing from 'pytest run pain' to 'git push joy' 🚀

Vittorio Banfi — Mon, 10 Feb 2025 10:17:52 +0000

Let's face it, fellow devs - we'd rather debug a production outage at 3 AM than write unit tests. Okay, maybe not that extreme, but you get the point! 😅 Today, I'm going to share how the folks at ScrapegraphAI (18k stars!) solved their testing woes with a solution so smooth, it's like they found a cheat code for the matrix.

The Testing Struggle is Real™

Meet ScrapegraphAI - the absolute wizards who created a tool that turns web pages into structured data faster than you can say "DOM manipulation." With 17k+ GitHub stars (flex much? 💪), they're kind of a big deal. But they faced the classic open-source dilemma: how do you keep your code base stable without becoming the testing police?

You know the drill - contributors show up with amazing features, but unit tests? crickets chirping 🦗

Let's be honest, writing tests for LLM integrations is about as fun as explaining to your PM why "it works on my machine" isn't a valid deployment strategy. The usual workflow looks something like this:

Write test
Run test
Question life choices
Repeat until caffeine runs out

Enter CodeBeaver: The Testing Hero We Didn't Know We Needed

Picture this: You push your code, and automagically, unit tests appear like pizza at a hackathon. Sounds too good to be true? That's what the ScrapegraphAI team thought until they gave CodeBeaver a shot.

Here's the secret sauce of how it works (no actual beavers were involved):

You open a PR (and maybe grab a coffee ☕)
CodeBeaver analyzes your code like that one colleague who actually reads the documentation
It mocks your LLM calls because nobody wants to pay OpenAI's bills for running tests
If tests fail, CodeBeaver's like "Is it you? Is it me? Let's figure this out" and fixes itself
Commits only the good stuff, neat and tidy

One PR went from "trust me bro, it works" to 90.7% test coverage faster than you can say "dependency conflict." 🎯
Check out an example PR here.

Why Should You Care? (Besides the Obvious Time-Saving Magic)

Because let's be real - we all want to write good code, but nobody wakes up thinking "YES! Today I get to write mock functions!" With CodeBeaver, you can have your cake and test it too. The ScrapegraphAI team now spends more time building cool features and less time playing "guess what this function does."

Ready to Level Up Your Testing Game?

If you're running an open-source project, CodeBeaver is FREE (yes, FREE as in "free pizza at tech meetups" free). For private repos, it's $12/month per dev - probably less than your monthly coffee budget.

Head over to codebeaver.ai and say goodbye to the days of "I'll write the tests later" (narrator: they never did).

Remember: Life's too short for manual testing. Let the beaver do the heavy lifting! 🦫✨