@sam,
I noticed this in the docs of https://github.com/xolvio/automated-testing-best-practices/blob/master/.scripts/README.md#npm-start
“FWIW, we prefer to run without a mirror.”
Can you expand on this a bit? Just curious why not run a mirror. I can think of some possible reasons, but curious your thoughts.
Thanks!
Mark
For staying focused and disciplined!
Running a BDD & TDD workflow in unison means that you start with a scenario-based domain test, and use that to drive the development of the domain with unit tests, then you add an acceptance test for a critical-path scenario, and drive the development of the supporting app/UI/persistence code with unit tests. You then fill out the edge cases and gaps with more unit tests. By the end of this workflow you have full test coverage. (Similar, but distinctly different to outside in testing).
You can do all of the above for the development of an entire feature, and when you stop coding, you can manually test the feature on the running local server. If you find any bugs, you start with the domain/acceptance/unit tests and fix it.
With this workflow, there is no need to keep a long running app, and the continuous resetting of state between the tests helps you identify any missing setup data when you do the manual test.
It’s worth noting that the suggestion is only for Chimp. For any integration tests, a mirror is advised. This is where the new Meteor test-app mode would be used.
Excellent explanation. Makes a lot of sense. Thanks!
shrop