After writing tests for my open source project last week, I've set up CI Workflow with GitHub Actions this week, to better protect my repo and automate the testing process.
Creating the Workflow
I set up a GitHub Actions CI workflow by navigating to the “Actions” tab on my repository page in GitHub. From there, I selected a Python application workflow template, which gave me a starting point for automating testing my code.
The workflow is defined in a YAML file located at .github/workflows/python-app.yml, which includes steps like checking out the repository, setting up Python, installing dependencies, linting the code, and running tests. The file configures the workflow to automatically run whenever code is pushed to the main branch or a pull request targets it, ensuring that the codes are linted and tested consistently.
Challenges When Creating the Workflow
The workflow didn’t pass at first due to some file naming and structure conventions. For instance, my requirements.txt file was originally named requirement.txt (missing the "s"), so the line: if [ -f requirements.txt ]; then pip install -r requirements.txt; fi
could not find the file. Renaming the file name to requirements.txt fixed the issue.
Similarly, the tests were initially in a single file called test.py. Pytest could not detect this file automatically. At first, I changed the workflow step to: pytest src/test.py -v to make it work. However, I wanted to follow best practices, so I moved the tests into a tests/ directory and split them into test_content_writer.py and test_util.py. Moving the tests also required setting the PYTHONPATH environment variable in the workflow:
env:
PYTHONPATH: ${{ github.workspace }}/src
This allowed the tests to access the code in the src/ folder. With these changes, the workflow passed using the simple pytest -v command, and the project now follows proper Python conventions.
Writing Tests for Others
Beside setting up CI workflow for my repo, I also wrote tests for my classmate’s repo, which introduced additional challenges. The project's modules were organized differently from mine, so I had to carefully read through the codes to understand how different components interacted before writing the tests. For instance, I used unittest in my project, while my classmate used pytest module when writing the test, and there were subtle differences in the test files. I also had to study the logic of the codes carefully before writing the tests, to ensure that the tests correctly check for the function's intent.
Lessons learnt from CI Workflow
I have learnt that CI workflow is a great way to provide automatic testing, where every push and pull request triggers tests to catch errors early. It's great that it gives developers immediate notifications when the workflow breaks, just like how I received the emails about failure of PR run when I was setting up the workflow. It can also promotes better team collaboration by using standardized workflows that reduce integration issues across multiple contributors.
Top comments (0)