You received this message because you are subscribed to the Google Groups "Transit Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to transit-develop...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/transit-developers/21ea294c-52d5-496c-ba44-985768b2b431n%40googlegroups.com.
Yes, we use this type of approach for testing the transitland-lib library that handles GTFS and GTFS Realtime parsing and validation for Transitland:
There are test case feeds for all three levels of GTFS static validation:
1. "bad entities" at the single row level: https://github.com/interline-io/transitland-lib/tree/master/test/data/bad-entities
2. validation errors that that involve entities in one or more files: https://github.com/interline-io/transitland-lib/tree/master/test/data/validator/errors
3. best practices: https://github.com/interline-io/transitland-lib/tree/master/test/data/validator/best-practiceshttps://github.com/interline-io/transitland-lib/tree/master/test/data/validator/best-practices
You'll notice that it's just the relevant files in each directory for each test case. At the time of running the test, the tooling injects the rest of the feed files that are needed to make the feed complete. In theory, the tooling could be expanded to also generate full feed archives for external use.
For GTFS Realtime, we create test cases in JSON and turn them into PB contents in the test rig. Much less coverage for that so far — it's mainly for testing matching logic: https://github.com/interline-io/transitland-server/tree/main/test/data/rt