OSD600 - Lab08

Link to Action
Link to PR I opened for testing to my partner's repo

Description

This post is about lab 08 for OSD600 course at Seneca College. This week, we learned CI(Continuous Integration). We integrated our testing into github workflow by setting them in .yml file.

Reflection

Q. How did you set up your GitHub Actions CI Workflow? What did the YAML for this workflow look like?

This is my .yml file:

name: codemage - ci

on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

jobs:
  build:

    runs-on: ubuntu-latest
    strategy:
      matrix:
        python-version: ["3.12"]

    steps:
    - uses: actions/checkout@v4
    - name: Set up Python ${{ matrix.python-version }}
      uses: actions/setup-python@v3
      with:
        python-version: ${{ matrix.python-version }}
    - name: Install Poetry
      run: |
        curl -sSL https://install.python-poetry.org | python3 -
        export PATH="$HOME/.local/bin:$PATH"
    - name: Install dependencies
      run: |
        poetry install
    - name: Test with pytest
      run: |
        poetry run pytest

When writing a letter, it's always difficut to start the fisrt sentence. Your brain go blank like "how should I start?", but after that, it's not too hard. Likewise, when I start writing a setting file or setting up an app, the first set-up is always harder. However, github provides the templates so I used them. With the template, it was not too hard.

yaml file looks to me like a json file without curly brakets and double-quotes. the foramt of yaml is intuitive and easy to understand, but the github action commands(or options) are not familiar yet.

Q.How did your partner's repo and testing setup differ from yours? What was it like writing tests for a project you didn't create?

She and I both used pytest; however, the testing code style was very different.
For example:

# Partner's Test code
def test_generate_comments_no_api_key(test_parameters):
    """
    Test that the function raises an error if no API key is provided or found
    """
    file_path, content = test_parameters

    with pytest.raises(RuntimeError, match="API key must be provided"):
        generate_comments(file_path, content, None, None, None, None, False)

This is her test code style

# my test code.
class TestLoadConfig:
    @patch("os.path.exists")
    @patch("toml.load")
    def test_load_config_file_exists(self, mock_toml_load, mock_os_exists):
        # Simulate that the file exists
        mock_os_exists.return_value = True

        # Simulate the contents of the file
        mock_toml_load.return_value = {
            "language": "Python",
            "OPENROUTER_API_KEY": "mock_openrouter_api_key",
        }

        # Call load_config function
        config = load_config()

        # Assertions
        mock_os_exists.assert_called_once_with(os.path.expanduser("~/.codemage-config.toml"))
        mock_toml_load.assert_called_once_with(os.path.expanduser("~/.codemage-config.toml"))
        assert config == {"language": "Python", "OPENROUTER_API_KEY": "mock_openrouter_api_key"}

    @patch("os.path.exists")
    def test_load_config_file_not_exists(self, mock_os_exists):
        # Simulate that the file does not exist
        mock_os_exists.return_value = False

        # Call the function under test
        config = load_config()

        # Assertions
        mock_os_exists.assert_called_once_with(os.path.expanduser("~/.codemage-config.toml"))
        assert config == {}

There are some parts that have the same style, but some of them are very different although we use the same test framework. So I asked ChatGPT, and it says there are a few different styles to support flexibility for various test cases.

1. function-based tests
2. class-based tests

I used class-based tests and she used function-based tests.

Q. What do you think of CI now that you've set it up for yourself?

My first impression is that it's so cool. Second, I think it's really good safety step. What often happens while working on a project is you fix one part and you are so happy and want to go to bed asap and have a good sleep, so you forget to test the code, and just push it to the repo. If you are working with others, this could be a disaster. And this CI prevents this mistake.