Testing strategy for legacy app with tightly coupled backend

Testing
1

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!

2

My 2c: If you’re wanting to do end-to-end and API tests I’d personally recommend leaning on a framework that’s designed for that stuff rather than using the Ember testing framework (testem, assume QUnit, etc). I’ve never tried it myself but I imagine you’ll run into some issues if you try writing end-to-end tests in the Ember framework. Whereas if you choose something built for that you can probably right end-to-end tests and API tests all in the same place and then use Ember tests for testing only rendering concerns.

As far as running them all together and code coverage and such… running them together is really as simple as some sort of script (node, bash, etc, really depends on how/where you want to run it) and I would look at code coverage tools that cover both front and backend. I’ve used code climate and codecov in the past which covered both (using ember-cli-code-coverage to generate the coverage reports for the front-end).

Definitely still worthwhile writing Ember tests but I would mock the API for any that you do plan to write. If using mirage I’d maybe start with integration/rendering tests, put your route definitions only in the test files (and not mirage config) so you’re testing only what you need (e.g. the component). Then if you update the API you’ll need to update the component, which means you’ll need to update the tests and therefore everything will hopefully stay roughly in sync.

Anyway, I think your strategy in general good and reasonable.