Our great sponsors
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
The first issue I tackled was to write unit tests for the getRandomMessage function. The function is responsible for picking a random message from the array and returning it, also it removes the message from the array so that the same message is not picked again. If there are no more messages left in the array, the empty array gets replaced with the messages array again, and so on. This function is called every time the Refresh button is clicked. (There is also a new feature recently added to the app that allows you to change emojis using getRandomEmoji function and works in a very similar logic described above. I also raised a PR to write a test for this feature here).
My first 2 PRs(1st & 2nd) were likely newbie level and I wanted to contribute to something more meaningful, something that would challenge me intellectually. I spent a good week or so stressing over what to contribute to next on the issues page, only to stress even more. What became clear to me was that if you are scrolling and scrolling through the issues page just to find the perfect issue for your use case, you're doomed... there are another 20K people doing the same just to get swags. That way, you are probably spending more energy searching than you would have spent on writing a new feature from scratch or a tough bug fix.
Unit testing framework was already implemented, using Vitest so I started hacking by setting up a coverage provider to explicitly identify the covered/uncovered lines and mentioned this to the maintainer in the comments. I used Istanbul 🇹🇷 for this purpose.
Ensuring everything is working as intended makes sense in principle, for example, I currently am developing a static site generator in cpp, palpatine, and as I develop it I stress about writing unit tests for it. Soon enough whenever a bug occurs I will be writing unit tests before debugging it. While writing unit tests though, I need to keep in mind that they won't stick around forever, my ssg tool is rapidly evolving; refactoring, adding new features, fixing bugs and shipping new releases day by day. That said, the unit tests will be obsolete soon enough and I might end up spending more time maintaining unit tests than actually developing the tool. Thus my philosophy at writing unit tests is to write them when they are actually needed, maybe when the consequences of breaking the code are high or when they are solving a specific problem.
Unit testing framework was already implemented, using Vitest so I started hacking by setting up a coverage provider to explicitly identify the covered/uncovered lines and mentioned this to the maintainer in the comments. I used Istanbul 🇹🇷 for this purpose.