Skip to content

Blocker: Need a test suite covering the standard RFCs to make timezones, DST, etc. reliable 🔰

TLDR summary: This is a call for new potential contributors who know some C programming and want to help make GNOME Calendar rock-solid by enabling us to do test-driven development for spec compliance, for anything related to timezones, DST, midnight, meetings.

one_does_not_simply_code_without_unit_tests

While this might not be easy to do for a "beginner programmer who does not know the C language" (and glib/GObject), it is a good "newcomer contributor" task for someone who already knows C programming and are looking to make a lasting quality impact on a popular FLOSS desktop productivity application that many people love.

Context (why we need this)

Some of the most varied and pervasive issues that have caused problems for GNOME Calendar users, for all of its existence, have been related to timezones (for meetings, travel, etc.), daylight saving time shifts, and incomplete adherence to the "iCalendar" standard specification commonly known as RFC 5545 (but it's also been updated/augmented in various ways with RFC 5546, RFC 6868, RFC 7529 and RFC 7986).

There currently are some unit tests in GNOME Calendar, but not nearly enough, and we need to cover a lot more in order to fix the pile of timezone-related issues (a tag I use to include pretty much anything related to timezones, DST, and midnight-related bugs).

We really need to use test-driven development here, otherwise these bugs will be a nightmare to fix and to keep fixed forever. Before we start fixing those bugs, we need as many unit tests as possible to cover spec compliance.

"Wait, but doesn't Evolution Data Server have a test suite?" you might ask… The answer is: Yes, and it covers a lot of things, but GNOME Calendar's test suite tests calendar-specific data structures, and whether we're parsing and sending the right data to e-d-s.

How your work will make an impact

By helping write unit tests to ensure GNOME Calendar complies with standard calendaring specifications, your contribution will make a huge impact in GNOME Calendar's future reliability, as an improved test suite will make it 100x easier for us to fix existing bugs while preventing introducing new bugs.

Doing this will also help us more confidently expand GNOME Calendar's featureset to handle meetings planning functionality.

Your skills and your mission

  • You need to know how to program in C, ideally with GLib / GObject, to be able to write new unit tests.
    Why can't we be using a simpler language like Python for those unit tests? Because you would need to introspect libgcal-private and generate bindings for that, and then we'd have a whole class of potential new issues: bindings issues...
  • You don't need to be an expert in C programming, but you will need patience and motivation/dedication to:
    1. Go through the list of timezone-related issues (first the open tickets, and maybe the closed tickets too afterwards) and: analyze those tickets (some of those tickets have really good detailed information provided by the commenters!), write a unit test to turn all those reproduction steps, usecases and corner cases into something that can be automatically tested now and in the future.
    2. If you can go the extra mile, then read the various specification documents like RFC 5545 and add more tests to cover as many parts as possible, even for things that "already work" in GNOME Calendar or issues that were not yet reported
    3. Bonus points if you also want to write tests to cover all the recurring events issues
  • You need to be ruthless in trying to make the most unforgiving unit tests.
    Our current code failing tons of tests is to be expected.
    The tests should not pass easily, or we would have:
    all_units_tests_passing

And then, if you want to go the extra mile, beyond unit tests, it would be awesome to have integration tests, too. Maybe once our codebase's accessibility support is better, you could use tools like Dogtail (or something else?) to do GUI and integration testing. This might require extra work to come up with a mock Evolution Data Server to interface with, to avoid messing with the user data on the system being tested, but that will require a lot more investigation.

If you would like to help, please let us know by getting involved here and our Matrix chatroom (see "Getting in touch" on this page for info), and sending merge requests. We will try our best to make it easier for you to get up to speed.

Current bugfixing status:

Edited by Jeff Fortin