Contributing to Telescope 🔭

The development of Seneca CDOT‘s planet-ending Telescope project is well underway, and I am happy to report on two very different contributions that I made over the course of the last three weeks.

Kicking off Kubernetes

Through my Hacktoberfest 2019 work—both with the service mesh community Layer5, specifically, as well as generally with Docker—I first came into contact with the concept of Kubernetes. Since then, I have been interested in learning more about Kubernetes, and was provided an opportunity to do so when I discovered that it was named amongst the MVP features for Telescope.

I capitalized on this opportunity to ‘open-source’ my research efforts into Kuberbetes by promptly opening up a Telescope issue (#4) dedicated to aggregating Kubernetes-related research and discussion. Since then, I have benefited from learning from those contributing to the thread while aiding in the facilitation and management of its progression.

I Jest

As the discussion thread that I started satiated my curiosity about Kubernetes, I decided to branch my efforts out towards a different MVP feature: (unit) testing.

I discovered that I was not the only one involved in writing Jest tests for Telescope: several other contributors were writing tests. While several of Telescope’s unit testing files were contributed alongside newly-introduced functions, most of the testing files were added separately, as the result of opened issues. At this time, several such issues remain open and without an assignee.

I wanted to contribute some unit testing to Telescope, but, knowing that many others do as well, I wished to take care to ensure that my work did not render the work of others redudant; that no one else was or will be unknowingly writing the same tests as I was. To do so, I decided to either create a new issue for a yet-untested source code file, or to assign myself to a relevant existing issue.

---

While searching for testing-related issues (the type: test label is very useful!), I came across the following issue with no assignees:

Issue telescope#197: two inactive blog filter functions require unit testing

This seemed like a perfect opportunity to contribute some needed testing to Telescope (specifically for the check() and update() functions of the recently-merged inactive blog filter).

Shortly after self-assigning to the issue (assuaging my aforementioned apprehensions), I was well underway to writing tests for the first of the two functions the issue names.

Syntax and Style

I am a fan of how Jest encourages documention through the use of common-language structural syntax, e.g. describe(...), it('should...'), expect(...).toBe(...), etc. Wishing for my Jest tests to maintain the same coding style of Lighthouse’s merged and pending test files (but also wishing to utilize the aforementioned syntax), I was a bit dismayed to discover that, across all of the aforementioned files, there exist few structural commonalities. Actually, it dismayed me enough that I opened an issue about it.

That said, I decided to utilize all of the aforementioned testing methods (and leave the issue of standardizing coding style to future contributors): I used describe() to create a ‘testing suite’ to encapsulate the two tests I wrote for the inactive blog filter‘s check() function. Within the same testing file, I believe that a second testing suite should be added to hold tests for the update() function.

Pulling it together

I was perhaps a bit hasty in making a pull request, as its first commit failed our CI testing! I quickly learned to fix my mistakes (through copious use of npm test), and my second commit to the PR passed the previously-failed tests:

Pull request telescope#211: adds testing for the inactive blog filter‘s check() function

I’m looking forward to soon having my first contribution to this project reviewed (and merged), as well as continuing to monitor the progress of both of the two discussion threads I’ve opened!