A Dive into Contributing to Adobe's Open Source: Adding Tests to @adobe/create-aio-lib

Introduction

Contributing to open-source projects offers a profound learning experience. This blog post delves into my journey contributing to Adobe's @adobe/create-aio-lib project, specifically focusing on the intricacies of adding unit tests to the CreateAioLibCommand.

Background

The endeavor began with Issue #103, a call to augment the CreateAioLibCommand class with robust unit tests. This was not merely a matter of validating existing functionality but also a strategic move to fortify the codebase against regressions and facilitate future development.

The Challenge

The primary challenge was crafting meaningful unit tests for a substantial command class, CreateAioLibCommand. This command orchestrates the creation of a new Adobe I/O Lib based on a specified template. The complexity lay in ensuring comprehensive test coverage while maintaining clarity and relevance.

The Approach

1. Setting Up the Environment

First and foremost, I meticulously set up the development environment. This included installing project dependencies, comprehending the project structure, and immersing myself in the existing codebase to understand its nuances.

2. Crafting Unit Tests

I approached unit testing with a systematic plan, covering various facets of the CreateAioLibCommand class. Tests were designed to scrutinize template cloning, file manipulation, parameter replacements, and error-handling scenarios. Here's a glimpse of what the tests looked like:

Copying the Template

One crucial functionality of the command is copying the template to a specified folder. I wrote tests to ensure that the template is copied successfully and that existing files are not overwritten when the overwrite flag is set to false.

it('should copy the template to the specified folder', () => {
  // Test implementation...
});

it('should not overwrite existing files if overwrite is false', () => {
  // Test implementation...
});

Cloning the Repository

The cloneRepo function is responsible for cloning a specified Git repository. I crafted tests to validate that the cloning process works as expected.

it('should clone the repository', () => {
  // Test implementation...
});

Removing the .git Folder

To ensure a clean slate, the .git folder needs to be removed from the cloned repository. I designed tests to confirm the successful removal of this folder.

it('should remove the .git folder', () => {
  // Test implementation...
});

Reading Parameters File

The readParametersFile function reads a crucial parameters file. I created tests to verify that an error is thrown when the parameters file is missing.

it('should throw an error if the parameters file does not exist', () => {
  // Test implementation...
});

Updating Package.json

The updatePackageJson function is responsible for updating the package.json file with relevant information. I wrote tests to validate this updating process.

it('should update the package.json file', () => {
  // Test implementation...
});

it('should throw an error if the package.json file does not exist', () => {
  // Test implementation...
});

3. Integrating with GitHub Actions

To automate the testing process, I integrated the tests into the project's workflow using GitHub Actions. A dedicated workflow configuration file dictated when and how tests should be executed. This setup ensured that tests ran seamlessly on each commit.

4. Creating the Pull Request

With the tests in place, I meticulously crafted a pull request (#104). The pull request not only highlighted the changes made but also provided insight into the motivation behind them and the testing strategy employed. A comprehensive checklist ensured that the changes aligned with project guidelines.

Results and Reflection

Upon the pull request submission, GitHub Actions automatically executed the tests, offering a swift verification of the changes. The results indicated that the new tests didn't introduce regressions and that all existing functionalities remained intact. As of now, the pull request awaits review and merge.

Conclusion

Contributing to projects like @adobe/create-aio-lib is a multifaceted experience. The addition of tests not only bolstered the project's stability but also set the stage for future enhancements. This journey has been enlightening, opening the door to the expansive world of open-source collaboration within the Adobe ecosystem.

Further Steps

While awaiting feedback on the pull request, I'm contemplating additional contributions. These might include improving documentation, addressing other open issues, or collaborating on new features. This experience has kindled a passion for open-source, and I eagerly anticipate more opportunities within the Adobe community.

Screenshots:

For a more detailed look, explore the pull request and the associated issue.

Happy coding!