Closed rmunn closed 2 months ago
More ideas: a helper class to manage various liblcm-related testing tasks:
Also do various liblcm tasks:
Basically, anything that's a multi-step process of more than 2-3 steps in existing S/R tests should turn into a helper method.
A thought about repeatability: I could use the NUnit attribute Property
on tests to mark them with the project that they use. Then a test fixture could use that value (which can be accessed through the TestContext) to get the current "tip" revision of the project before starting the test, and in the teardown, reset the project to that tip revision so that we remove any commits we pushed.
Now that LexBox and Language Forge can be run side by side, it should be possible to set up end-to-end testing of Send/Receive scenarios with a real Language Depot deployment, rather than a simulated one. A typical test might go as follows:
That's a lot of steps that currently have to be done by hand, but with LexBox and Language Forge running side by side on a developer machine (plus MkFwData and SplitFwData tools becoming available in the flexbridge repo so that the E2E S/R tests can use them), all of that will finally be able to be automated.