Spy on jasmine function from an Angular library is not working

[C0ZEN]

I have an Angular library containing functions like "export function myFunction".
The project with the error have this library as a dependency and when I want to spy on the function, the error below is display:

myFunction is not declared writable or has no setter

Now the real world example:

A simple function from the library:

export function isNotEmptyString(value: any): value is string {
  return _.isString(value) && !_.isEmpty(value);
}

The dts of this function once packaged:

export declare function isNotEmptyString(value: any): value is string;

To spy on the function, I must have an object at some point.
So I use a custom module import to achieve this.

The spy on error:

import * as MyLibfrom 'my-lib';

const isNotEmptyStringSpy = spyOn(MyLib, 'isNotEmptyString').and.returnValue(false);

And the error is:

isNotEmptyString is not declared writable or has no setter

Now, if I use a spyOnPropety:

import * as MyLibfrom 'my-lib';

const isNotEmptyStringSpy = spyOnProperty(MyLib, 'isNotEmptyString').and.returnValue(() => false);

And the new error is:

isNotEmptyString is not declared configurable

I also tried to use differents module inside the tsconfig.json compiler options.
Like commonjs, CommonJS, ES2015 and ESNext.
There is no difference.

tsconfig.json

"compilerOptions": {
  "module": "commonjs"
}

Does anyone have a suggestion?
I am stuck with this :/

Thanks !

Environment:

"karma": "4.4.1"
"jasmine-core": "3.5.0"
"@angular/core": "9.0.5"

[alan-agius4]

I'm sorry, but this issue is not caused by Angular CLI.

Please see the following Jasmine issue: jasmine/jasmine#1414

[sgravrock]

Hi, I'm a Jasmine developer. I was able to reproduce this. It looks like the property descriptors that Angular 9 generates for module exports are marked read-only. Specifically, they have a getter but no setter and have configurable: false. As a result, it's not possible to overwrite the property with a spy.

I don't think there's anything Jasmine can do to fix this. We can only play by the rules of the language, and if the rules say that a property can't be set then we can't set it.

@C0ZEN Your best bet is probably to use dependency injection for anything that you want to spy on, rather than trying to spy on module exports.

[C0ZEN]

@sgravrock thank you for your time and sharing this information.
Do you think that Angular could provide a way to generate configurable: true or should I just take that other path and refactor all my tests ?

[alan-agius4]

Do you think that Angular could provide a way to generate configurable: true or should I just take that other path and refactor all my tests?

These are actually not emitted by the Angular compiler but rather TypeScript and Rollup. Also, in this case it wouldn't be correct to change the the module exports definition to be configurable, because that shouldn't change.

I do agree with @sgravrock, that you should use DI if you want to spyOn.

[C0ZEN]

@alan-agius4 ok, fine, so I must find a way with the dependencies as they are.
Nonetheless, are you talking about Angular's DI ?
Because pure functions, as well as I am aware of, have nothing to do with the DI since there is no decorator to make them available as tokens.

[rairulyle]

I am having the same problem. We basically have a utility package that has pure functions and we can't spy on them. We can't complete the coverage because of this.

@C0ZEN , have you found a solution?

[C0ZEN]

@Skullpluggery I have found a workaround (which I do not like but I had to move forward with ng9, so no choice here).
I changed my way to test.
I removed all the spies on pure functions coming from the library.
So basically, instead of writing unit tests with a bunch of spies to control the behavior, I removed them and let the real behavior of the library be itself.
Hear me out, this is good thing for most of the cases, but sometimes I prefer to use a spy and now this is no longer possible.

[clydin]

For an Angular CLI built application, construction of the namespace object is performed by Webpack within its runtime.

A module namespace object is considered an exotic object by the ES standard and has very specific behavior (each of the internal methods are customized). The relevant section is found here: http://www.ecma-international.org/ecma-262/6.0/#sec-module-namespace-exotic-objects
Of note in that section is that each export property should be writable. The generated Webpack namespace object appears to create accessor property descriptors instead of data property descriptors (ref: http://www.ecma-international.org/ecma-262/6.0/#sec-module-namespace-exotic-objects-getownproperty-p). However, even if this were changed, namespace objects are not intended to be mutated and other bundlers (such as rollup) also do not allow this behavior. Some type of import mocking setup could also be an option for this scenario.

[shwetasingh237]

Adding "module": "commonjs" in tsconfig.spec.json lets you spyOn exported functions in angular.

1.abc.spec.ts
import * as MyLibfrom 'my-lib';

const isNotEmptyStringSpy = spyOn(MyLib, 'isNotEmptyString').and.returnValue(false);

2. tsconfig.spec.json
   "compilerOptions": {
   "outDir": "../out-tsc/spec",
   "module": "commonjs",
   "target": "es5",
   "types": ["jasmine", "node"]
   }

Note that you need to add module in tsconfig.spec.json not in tsconfig.json.

[gkamperis]

@C0ZEN if the function is pure you are ok.

But how would you control a random() function for example?

And what if you want to test how many times a function was called or the params it was called with?

I also had @shwetasingh237 solution and works great for testing.

[C0ZEN]

@shwetasingh237 @gkamperis either Angular/jasmine has changed (highly improbable) and the problem is gone or you are just not using a good reproduction of the problem.

Just a quick reminder of the problem:

• Create a library with pure functions and packaged by ng-packagr
• Consume the library in an Angular application
• Spy a pure function from the lib

Changing the module to commonjs is a good solution INSIDE a library nevertheless this is no longer working OUTSIDE of the library.
Please @shwetasingh237, could you confirm that you are testing in this context because if this is true, then a "good" workaround is now possible and this would be awesome.

[gkamperis]

@C0ZEN I don't understand why the setup is important.

I had the same issue going to ng9 with tests that used jasmine.spyOn() on a local module function and on other 3rd party package functions (is purity is important in this case?).

Also what is the difference between your own module function and an external ng-packagr packaged function? spyOn works the same.