Setting Up CI and Writing Tests for Collaborative Development

Introduction

In this post, I summarize my experience setting up GitHub Actions for Continuous Integration (CI), writing tests for my own project, and contributing to a partner's repository.

---

Setting Up GitHub Actions for My Project

To automate testing and linting, I created a CI workflow in .github/workflows/ci.yml. Below is the YAML configuration:

name: Python CI

on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repository
        uses: actions/checkout@v3

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

      - name: Install dependencies
        run: |
          python -m pip install --upgrade pip
          pip install -r requirements.txt

      - name: Run linting
        run: |
          pip install black flake8
          black . --check
          flake8

      - name: Run tests
        run: |
          pytest

Challenges Faced

While setting up CI, I encountered issues with YAML indentation and ensuring that tools like flake8 and black worked well together. Debugging these problems taught me how important it is to have consistent configurations across tools.

Outcome

With CI in place, every commit is automatically tested, and I receive instant feedback on potential issues. This has significantly improved the reliability and maintainability of my project.

Writing Tests for My Partner’s Repository

I collaborated on AutoCommentingTool, a JavaScript-based project. Writing tests for someone else’s project was a unique experience and helped me understand the importance of clear documentation and modular code.

Key Differences

My Project: Python-based with pytest, black, and flake8.
Partner’s Project: JavaScript-based with Mocha, Chai, and Sinon.

Tests Written

I focused on testing file operations (writeIntoFile) and contributed additional test cases for edge cases such as empty strings, nested paths, and handling write failures.

Here’s a test I wrote for file operations in the repository:

it('should throw an error if writing to the file fails', async function () {
    const testData = 'This is a test comment.';
    const testFileName = 'testOutput.js';

    writeFileStub.yields(new Error('Write failed'));

    try {
        await writeIntoFile(testData, testFileName);
        throw new Error('Expected error was not thrown');
    } catch (err) {
        expect(err.message).to.equal('Write failed');
    }
});

Challenges Faced

Understanding unfamiliar code and framework setups.
Adjusting to a different language (JavaScript) and testing tools (Mocha/Chai).

Lessons Learned

A well-documented project is crucial for onboarding contributors.
Writing modular and testable code makes it easier for others to add tests.

Reflections on CI

Setting up CI and experiencing its benefits firsthand has transformed how I approach development. Here’s what I learned:

Time Savings: Automating tests saves time by catching issues early.
Quality Assurance: CI enforces consistency and ensures that only well-tested code is merged.

Collaboration: CI simplifies collaboration by providing a clear picture of the project’s health.

I now see CI as an essential part of software development. It might take time to set up, but the benefits outweigh the initial effort.

Conclusion

This project was a valuable learning experience that improved my understanding of CI, testing, and collaboration. Setting up CI for my project made it more reliable, while contributing to a partner’s project helped me grow as a developer.

I look forward to applying these skills in future projects and advocating for the use of CI in team settings to improve code quality and collaboration.