Contributing to my favourite open-source project – Check

Reading Time: 4 minutes

It has been a while since we introduced CodeceptJS as our test automation framework for e2e tests at my current workplace. Since then, we updated the framework multiple times for changes we needed or were requested from other users. CodeceptJS is a relatively new open-source NodeJS framework which has fantastic features such as the ability to utilize different well-known test runner libraries such as Protractor and WebdriverIO. The popularity amongst users is steadily increasing, and its future looks bright.

Contributing is key!

Open-source projects are rarely as perfect and bug-free as we may wish. Since such projects have many contributions, it is only natural that different contributors are not aligned, therefore unwanted behaviour might occur. As this is not a paid tool/library, there is no legal obligation or SLA for issues to be fixed in a timely fashion. That means that users have to attempt fixing issues themselves if its something which is blocking them.

We experienced this when we decided to try out a new REST API library which was introduced in a recently released version. As I was not very experienced with API testing back then, I initially thought that I was setting it up incorrectly. Luckily, I was not the only one who encountered the issue. Searching through the repository’s open and closed issues, as well as posts on StackOverflow was in vain.

After considering all scenarios, we came up with two options: downgrade the version to the point where the feature was working, or contribute a fix and solve the issue. Unfortunately, the latter is not a popular choice, as most people in the industry treat open-source software as an enterprise product, with expectations that someone will fix the problem soon. We decided to be brave and dedicate some time to correct the problem and ultimately contribute to our beloved CodeceptJS framework.
Immediately, I started to dig into the code. A few hours later and, it all made sense! Found it! The issue was detected! But, what now?”

I tried the fix on my local environment, and it worked! After coming this far, I did not want to stop there; I wanted to share it with the world (or at least the codeceptJS community).
So how can I do it? Although I thought it would be an easy and straightforward process, it was not, at least for my first time.

So my journey begins.

What is so hard about it? All you need is to have to have an account on GitHub, clone the project, create a branch, make the change, commit your code with a meaningful comment, push and create a PR. Right? Well, not quite.

The good thing about GitHub is that you can see everything that is happening on your pull request so after my push to the branch, I was refreshing the page regularly, full of expectations, awaiting feedback.

Rejection

The owner of the repo has correctly set up a series of checks which are automatically run on each PR. The first one, in this case, was Codacy, the static code analysis which checks code style, complexity, security, duplication and unit test coverage. So far so good, I passed the first one!

The second check was Travis CI, which simply runs the existing unit tests. There were multiple tests both unit and e2e, and they started to fail big time. This was my first major challenge.
While checking the errors my PR had caused, I received some feedback. I had to change, update and create new unit tests, they were actually designed to pass with the incorrect behaviour of the code. This was not easy to digest, as I did not know anything about unit tests. I thought that I would never be able to do it. However, it made no sense to give up now!

Unit tests?

Mark Manson once said “Being wrong opens us up to the possibility of change. Being wrong brings the opportunity for growth.” The question is what if everything would be green, what if all unit tests would pass? I simply would not have learned anything from my pull request.

unit_tests_contributing_open-source_testautonation

As I did not have any knowledge or experience creating unit tests, I asked developers to help me out. “I am busy now, can you please ping me later?”, Sounds familiar? I usually don’t like waiting, so I started to learn more about unit tests on my own and how to improve them. Piece by piece, failure after failure, I managed to create and fix some failing tests with the help of my QA colleagues and finally pushed my changes to the branch.

All green: time to merge

all_checks_contributing_open-source_testautonation

Full of expectations, I waited for the Travis run to finish. No failures, all green. A few hours later, I received one last comment saying: “good job, all good from my side, we can merge”.
Honestly, at that moment I felt amazing! For the first time, I contributed to something used by many people around the world. So If you have such an opportunity, do not hesitate or be afraid to change something. Do not be afraid to learn through failure!

P.S. This was my first blog post as a guest author for TestAutonation. If you are interested in doing the same, contact the team here and give your contribution to this growing community!

Michal Trúnek

QA Engineer who loves Calisthenics

Leave a Comment