Developer sees that there is unit test coverage for GTFS Schedule validate

[ohrite]

As a developer making changes to the GTFS Schedule validation logic,
When I make a breaking behavior change,
I can run pytest and see a corresponding failure message

---

Notes:

• This validation logic relies on a script in the jobs/ directory, look at the prior example of testing the GTFS-RT Typer app
• Do not test the inside of the space capsule https://speakerdeck.com/skmetz/magic-tricks-of-testing-railsconf
• The result artifact should be in a predictable location, and containing the same information, given the inputs
• If your test depends on fixture data, such as a file at a specific location, make sure it’s there in setup
• More integration is better than less integration
• Use pytest’s VCR plugin to capture network traffic, but configure it to ignore authentication

[lauriemerrell]

I have a question about intended scope of this work. Based on the conversation last Tuesday, I had added "add Pytest tests for the validator jobs" to my scope in #4350, and assigned myself to this ticket today.

However, looking at it now, because the GTFS validator job is still a PodOperator I am not sure what is most appropriate: to add Pytest tests in the jobs directory with the Python code for the operation or to write tests that can be run from within Airflow against the image that is actually used by the PodOperator.

Basically, my question is: Is there a goal of refactoring the schedule validation job to no longer be a PodOperator before the Compiler upgrade, so that tests against the Python code are enough (they can be used to support that refactor and then be ported over to work against the refactored version)? Or is there a need for tests on the task as it is currently configured as a PodOperator? Or both? I do not see any examples of unit tests for a PodOperator I should use as an example of preferred practices (so can start from scratch on that if needed) but wanted to check before starting on that.