I’m working on cleaning up a legacy ember app from a few years ago, and I’m hoping to write some tests to ensure my cleanup doesn’t break anything (it currently has no tests at all). The app is tightly coupled (via Ember Data) to a Node/Express backend that lives in its
/server directory (I’m considering separating it out into its own repo at some point, but that’s another story). The backend, in turn, has no data storage of its own, but makes API calls to several other services, which I’d probably need to mock.
Because they’re so tightly coupled, I’d prefer to have integration tests testing the Ember app along with its backend, instead of (or at least in addition to) mocking the backend with something like mirage, so that I don’t have to worry about my stubs getting out of sync with the actual API interface.
I have a few questions about my approach here:
- I’m assuming that I should start with end-to-end integration tests to make sure I don’t break anything, then begin to add unit tests later on to deal with specific edge cases or make debugging easier. Does this seem reasonable?
- In addition to testing the backend through integration tests encompassing both the ember app and the backend, I’d like to tests the backend by itself as well. Would it be possible to integrate those tests in some fashion, so that I can (a) use one test command to test both the server and client, and (b) measure code coverage for the backend, taking into account both types of tests?
- Any other advice about how to test this behemoth?
Thank you so much for any help!