Setting up CI and automated testing

In my repository Repo-snapshot I set Continuous Integration (CI) workflow with GitHub Actions by creating two folders: .github/, workflows/, and a file named ci.yml

## Structure

repo-snapshot/
├── .github/
│   └── workflows/
│       └── ci.yml
├── src/
│   ├── cli.ts
│   ├── file-collector.ts
│   ├── file-utils.ts
│   ├── git-info.ts
│   ├── index.ts
│   ├── output-builder.ts
│   ├── toml-config.ts
│   └── tree-structure.ts
└── tests/
    ├── file-utils.test.ts
    ├── index.test.ts
    └── output-builder.test.ts

The workflow configuration looks like this:

name: CI
on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Setup pnpm
        uses: pnpm/action-setup@v2
        with:
          version: 10
      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: "20"
          cache: "pnpm"
      - name: Clean install
        run: pnpm install --frozen-lockfile --prefer-offline
      - name: Check formatting
        run: pnpm format:check
      - name: Lint
        run: pnpm lint
      - name: Test
        run: pnpm test

I set the CI to trigger on any Pull Request or Push to the main branch, which runs checks for the following:

1. pnpm setup
2. Node.js setup
3. dependencies installation
4. code formatting
5. ESLint checks
6. testing

Since I use pnpm to manage dependencies, it is necessary to set up pnpm first to ensure all dependencies are installed correctly. Next, I set up Node.js to make sure dependencies are installed for the correct Node version defined in package.json. Then, the workflow checks whether formatting, linting, and tests run successfully.

By automating formatting, linting, and testing in CI, I learned how much time and effort can be saved by automatically ensuring code quality on every pull request or push. This approach helps catch errors and maintain standards without manual intervention and reassures me that even if I or collaborators forget a step, CI will enforce it. After setting this up, I became confident that future projects would benefit from the same workflow—resulting in more consistent code, fewer bugs, and faster feedback. Overall, incorporating these checks into CI reinforced the importance of automation in development pipelines and convinced me this is a vital strategy for every project.

Since completing the CI workflow, I feel it greatly benefits the project. Even for different or new projects, if anyone forgets to format, lint, or properly test code, CI reminds the coder of problems in the pull request and blocks any code that could cause side effects.

After setting up the CI, I contributed to another project, Repopal, by creating unit tests.

Its testing structure differs from mine in folder naming, directory layout, and configuration files:

## Structure

repopal/
├── __tests__/
│   ├── unit/
│   │   └── file.test.ts
│   └── vitest.config.ts
└── src/
    ├── file.ts
    ├── fileMap.ts
    ├── git.ts
    ├── loadConfig.ts
    ├── main.ts
    └── output.ts

Because the project differs somewhat, I first read and understood its structure. Then I chose a relevant part to create unit tests. If the testing framework had been different from mine, I would have had to learn a new one. Fortunately, the project also uses vitest, so I was able to write tests more easily than if it had used another framework like Jest.