How Can You Test a GTFS Service Calendar Parser?

Start with a tiny calendar

A service calendar parser turns weekday rules and date exceptions into a decision: is this service active on a particular date? Test that decision with a deliberately small fixture whose expected answers can be checked by eye. Include a service identifier, a start date, an end date, and weekday flags. Choose a short span that contains both active and inactive weekdays.

Exercise weekly rules and exceptions

For example, set Monday through Friday active over a Monday-to-Sunday interval. Assert that a Wednesday is active and a Saturday is inactive. Then add a date exception that activates the Saturday and confirm it becomes active. Add a separate exception that removes a normally active Tuesday and confirm it becomes inactive. These paired assertions catch parsers that ignore exceptions or apply them in the wrong direction.

Keep the test data explicit. If the calendar format uses an exception type or code, give the fixture a named constant or helper so the intended meaning is clear. Test a date with no exception as well: otherwise a parser that treats every date as exceptional could pass unnoticed.

Probe the range edges

Dates just outside the calendar's start and end should not inherit the nearest weekday pattern. If a feed covers Monday through Friday, test the preceding Sunday and following Saturday and expect no service from that calendar. Also test the exact first and last dates to catch off-by-one comparisons.

When date exceptions can appear outside the regular range, decide from the format and application contract whether they should take effect, then encode that behavior separately. Avoid assuming that a weekday match alone makes a service valid beyond its declared range.

Make failures easy to diagnose

Use table-driven cases containing the date, expected active state, and a short reason such as “removed Tuesday” or “after end date.” On failure, report the service identifier and date. If possible, test the parser's calendar result before testing downstream trip selection; this narrows the fault to date logic rather than later schedule code.

A compact fixture can cover many rules without depending on a live feed. Keep one case for each behavior and add regression cases whenever a real parsing defect appears. The resulting suite becomes an executable description of what the application means by a service day.