We had to set up continuous integration (CI) in our own repository if we hadn't done it yet and contribute tests to a classmates project. This weeks blog dives into my experiences with GitHub Actions, the challenges of writing tests for unfamiliar code and my thoughts on CI.
Setting up GitHub Actions CI Workflow
Setting this up was a bit confusing at first, but after reading different resources online and going through the starter workflow files for many languages provided, things became clear. I started by creating a .github/workflows directory where I added node.js.yml which is triggered on pushes and PRs to my branch. The set up was quick and everything worked well.
I later created the add-more-tests branch where I added, committed and pushed new tests for the readFileContents function in the fs-utils file. I opened a Pull Request which triggered my CI workflow and I could watch the action build and pass. I tried breaking my code and watched the CI build fail as expected, then fixed the failing test and pushed again, finishing with a green Action.
Differences in my Partner's repository and Testing setup
My classmate's repo was a Go based CLI tool similar to mine but with different modules. The CI workflow was in the go.yml file and the testing focused on scanner utilities so I had to familiarize myself with their FileInfo struct and directory tree generation logic.
I forked their repo, created the add-more-tests branch and added unit tests for the generateDirectoryTree function in scanner.go. It was quite challenging especially the testing part, but searching helped me and I was able to run the tests with the command go test -v ./pkg/scanner/ and check coverage with go test -cover ./pkg/scanner/ and was happy to see the coverage improve from 8.2% to 30.3%. I communicated with my partner and confirmed I created a Pull Request.
My thoughts on CI
After setting this up, I think CI is a game changer for reliability. Before this, I ran tests manually which was time-consuming and error- prone but now, I catch issues early with automated checks on every push or pull request. It is essential for teams ensuring code stays stable and nothing breaks. CI boosts confidence in deployments.
Top comments (0)