angular: Unexpected behavior for providedIn services in TestBed

We are experiencing this issue as well in a new rather large angular project. We have a lot of services that depend on other services and unless you check all dependencies manually and include them in the TestBed, you end up with integration tests instead of unittests without even noticing. It is almost certain that developers forget to mock dependencies. I’m really surprised that this done on purpose as it seems like a major flaw to me.

Does anyone have a workaround for this or is there any way to check for non-mocked dependencies in an existing code-base?

I’d like to tackle this issue and ensure that testing module is always isolated / empty. I’d say that this behavior should not change / services provided in root should fail to resolve during tests.

EDIT: Managed to reproduce the issue by adding additional test in test_bed specs. Currently tracked down where provider is created and looking for a way to change the behavior in test. Possibly by overwriting provider def and removing providedIn option / or checking that early in custom test injector.

UPDATE TO REMOVE ALL DOUBT:

This will not be integrated into angular-eslint because it is recommending something which goes against the current recommendations of the Angular Team.

This is why I closed the issue requesting this on angular-eslint.

The below is merely intended as helpful guidance for folks who end up wanting to enforce things in their own codebases and incorrectly believe they need to have dedicated rules for forbidding certain syntax.

Creator of typescript-eslint and angular-eslint here 👋

This was flagged up to me via a request to create a dedicated rule for this case. I am hesitant to do that for something which is still evolving as a topic and does not yet have a dedicated solution from the Angular Team.

However, you do not necessarily need to create a dedicated lint rule for this, the built-in ESLint no-restricted-syntax rule could be used to achieve the desired result:

{
  "rules": {
    "no-restricted-syntax": [
      "error",
      {
        "selector": "Decorator[expression.callee.name=Injectable] Property[key.name=providedIn][value.value=root]",
        "message": "Do not use `providedIn: root` in Injectables"
      }
    ]
  }
}

Example of it in action:

https://typescript-eslint.io/play/#ts=4.5.2&sourceType=module&showAST=es&code=JYWwDg9gTgLgBAbzgSQHYCsCmBjGBDAIwBtM4BfOAMyghDgHIABPVAcwFci8oB6baTPQDcAKBGM0WXIRIAKBCLhK4YGgDdgAE0ya0ALgY0IMeiLIBKEdi4BnG3ABiECIjIigA&rules=N4Igdg9gtATgpgZwC4wJYGMlwCZQQTzCQEMAPEALgG0Q4YYIYQAaUBOAGzk0cpABFujYkkZU4pAA7wECVBDAA6dMQ5c4isMQC2cALwBJMACtuJAEZcAugAIbABQaS6SfFQDWcfJp37pEADdUbBwjKyoA1QBXDUiOGL0GCCQrFhBdWWIAczg+fggbSCQbKPYbAAN-IJDsIwobJKRym1QwGyNTTGJLRBAAXys+oA&tsConfig=N4IgpgHgDmBOCWBbMA7ALgQwDYBEwGMB7WDNYgZxAC41YBXMAGnEXjTyJLNgFkxMAJqQzVaDAL5A

I do agree with @shairez too, the problem with the proposed solution of #26088 that it would break a lot of tests (at least from my perspective and for a lot of projects I’ve seen) and therefore it should be considered a breaking change. Also in the pr it is correctly stated out that this kind of behavior is quite nice for integration tests. To advance with this in a non-breaking way I would rather create a new method in the TestBed, e.g. TestBed.configureUnitTestingModule.