Adding any tests to app.component.spec.ts (even empty ones) causes other tests to fail

After migrating from @angular/cli to this testing setup, two of my tests started failing. Both of these tests are long standing and have not been modified in ages.

* [It passes a clicker through to service](https://github.com/lathonez/clicker/blob/master/src/components/clickerForm/clickerForm.spec.ts#L28-L37)
* [it does a click](https://github.com/lathonez/clicker/blob/master/src/components/clickerButton/clickerButton.spec.ts#L31-L39)

I tried [re-writing one of the tests](https://github.com/lathonez/clicker/commit/094bc82f0ba5cdbc590372190bf6ddd1746fa9f6) using the latest recommendations on Stack Overflow, to no avail.

To cut a very long story short, I figured out that [commenting out the tests](https://github.com/lathonez/clicker/commit/9040c1d7c068853f1706602216c3036e4056e2c4) in `app.component.spec.ts` let the tests run fine.

I also tried empty tests (nothing in the test block at all), as well as adding an `afterEach() => destroy`, which didn't help.

**To Replicate**:

* `git clone git@github.com:lathonez/clicker.git`
* `cd clicker`
* `npm install`
* uncomment the tests in `app.component.spec.ts`
* `npm test`

**Note**

I do not expect a solution to this problem, but I consider leaving the repo in it's current state (as long as we are unable to explain the behaviour) pretty dangerous in terms of other user's time. There is nothing at all to make you think that these tests would be affected by `app.component.spec.ts`, indeed everything we know about the unit testing setup tells us otherwise. You can easily sink several hours into this problem before coming to this point, or just getting frustrated and binning your perfectly valid tests.

Start with app.component.spec.ts and the two linked specs in src/components/clickerForm/clickerForm.spec.ts and src/components/clickerButton/clickerButton.spec.ts. Clone the repository, run npm install, uncomment the app.component.spec.ts tests, and run npm test to reproduce the interaction. Done means explaining why the tests affect one another and restoring independent test execution.

Written by the indexing model from the issue text.