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.