fix(store): silence console hints in tests

[markwhitfeld]

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/ngxs/store/blob/master/CONTRIBUTING.md#commit
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

[X] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[ ] Other... Please describe:

What is the current behavior?

Currently when tests are run with NGXS the console is filled with noise regarding the hint to turn on the developmentMode during Angular dev mode.
Issue Number: #701

What is the new behavior?

When NGXS is being run during tests the console hints will be supressed.

Does this PR introduce a breaking change?

[ ] Yes
[X] No

[markwhitfeld]

Waiting for feedback from the angular team on my approach to checking if Angular is in Test mode.
https://twitter.com/MarkWhitfeld/status/1071472090920992773

[markwhitfeld]

Also still trying to figure out how to write tests for this!

[splincode]

@markwhitfeld @eranshmil

I think this is a difficult operation if the number of iterations in this method is more than it seemed. I think this is a difficult operation if the number of iterations in this method is more than it seemed.

{
developmentMode: false,
silentWarning: true // disabled recommend
}

[eranshmil]

The function is memoized, so it will run only once.

[markwhitfeld]

I do not want to require developers to add options to all their test setups. This would not be a good experience at all. My aim is to reduce the boilerplate required in the tests.

[splincode]

how hard is the operation? How many iterations will be in production mode?

the number of providers may be a huge?

[markwhitfeld]

These compiler options will iterate over no more than 10 providers and this list does not get affected by the providers in your app. These are stock standard.

[eranshmil]

@markwhitfeld @splincode
https://github.com/angular/material2/blob/b8c1024a09f89eab39a213fe13f47d529dccdd74/src/lib/core/common-behaviors/common-module.ts#L65
This seems like a cleaner solution.
Tested locally and it works.

[splincode]

@markwhitfeld ping

[markwhitfeld]

@eranshmil Nice find but unfortunately it assumes karma and jasmine:

  private _isTestEnv() {
    const window = this._window as any;
    return window && (window.__karma__ || window.jasmine);
  }

People could be using jest, tape, ava, mocha, etc.

[splincode]

@markwhitfeld I believe you need to use the solution, which is found @eranshmil

[markwhitfeld]

So, my tweet received a few interesting answers:
https://twitter.com/MarkWhitfeld/status/1071472090920992773

Some of the options are:

1. What I have done by looking for the MockNgModuleResolver in the COMPILER _OPTIONS
   My concern is the comments in this file: https://github.com/angular/angular/blob/cf0968f98e844043a0f6c2548201f3c0dfd329a7/packages/compiler/testing/src/testing.ts
2. platformRef.injector.toString().includes('TestingCompilerFactory');
   Does a toString() on all providers so could be expensive (although we can memoize)
3. platformRef.injector.toString().includes('coreDynamicTesting');
   Does a toString() on all providers so could be expensive (although we can memoize)
4. platformRef.injector.get(TestBed, null) !== null;
   Requires a ref to TestBed from @angular/core/testing which is included anyway when you have angular. Apparently this works (even though TestBed is an interface and not a class.
   Could alternatively test for TestingCompilerFactory or coreDynamicTesting in this way too...

Which approach do you prefer?
@eranshmil @splincode @deebloo

[eranshmil]

For me, the last one seems better than the others.

[splincode]

good

platformRef.injector.get(TestBed, null) !== null;

[markwhitfeld]

Great, I'll make the change and run it through the tests I wrote for it. Holding thumbs!

[markwhitfeld]

Used the simpler mechanism of checking for the test mode.
Unfortunately the tests I wrote do not apply anymore because the mechanism uses the internal injector and not the platform injector. I have tested it with the integration app and with the local test run.
@splincode please review and merge if happy.