Test against real Lambda Feedback exports - #41
Conversation
m-messer
left a comment
There was a problem hiding this comment.
The filter refactor is a great change.
Testing an exported version of a set from LF is a great idea, but I think it is the wrong implementation. If the LF import schema changes, the test code won't detect it, and all test documents will become stale and need to be regenerated. A more complex but more robust approach would be to provide a file to in2lambda, send it to staging or some specific test environment, and then export the set to validate the entire end-to-end pipeline.
|
Thanks — agreed that a staging round trip is the stronger test, and it's the right thing to add once there is an import endpoint to call; today the docs only describe uploading a zip in the teacher UI, so nothing in the package can drive it. In the meantime the fixture test still earns its place: it is what stops the writer emitting keys Lambda Feedback never exports, and it runs offline in seconds. If the import schema changes, the fixture is re-exported from Lambda Feedback and the diff shows exactly what moved — that is a feature, not staleness. We're integrating on a |
in2lambda writes files for Lambda Feedback to import, but nothing checks its output against what Lambda Feedback actually produces. We have a real exported question set, and we will accumulate many more; adding one to the test data should never require changing code.
Done when a real export is part of the test data, the suite loads it, writes it back and compares, and dropping another export beside it is picked up on its own. The filter tests need the same treatment: they name each filter by hand, so a new filter is covered only if someone remembers.
The first real export is already on main in tests/fixtures/exports/, with a README describing the export's JSON. Those files are exactly as Lambda Feedback wrote them and must stay that way.
Workbench ticket t19.