Open YoeriNijs opened 2 years ago
What about the following? It's not ideal but does the trick I think.
Adding another expect expect(service.bucket).toBeInstanceOf(Set);
will still assert the type of the bucket to ensure the implementation did not change, making it less dangerous to use as Set
or service.bucket
directly.
describe('DocumentService', () => {
const createService = createServiceFactory<DocumentService>({
service: DocumentService,
mocks: [HttpClient]
});
it('should call the endpoint', done => {
const spectator = createService();
const httpClient = spectator.inject(HttpClient);
httpClient.get.andReturn(of({}));
spectator.service
.getDocument('documentId')
.subscribe(() => {
expect(httpClient.get).toHaveBeenCalledWith('/api/documents/documentId', {
context: withCache({
ttl: 10_000,
bucket: service.bucket
})
});
expect(service.bucket).toBeInstanceOf(Set);
done();
});
});
});
I'm submitting a...
Current behavior
The TypeScript compiler throws a TypeError when one is testing a service that uses the CacheBucket.
Example service:
Which causes the following in a Spectator driven test that is executed by Jest (we do not use the createHttpFactory here since we explicitly want to validate the cache context):
Since CacheBucket only extends Set without applying anything else, it is possible to fix this issue by typing the CacheBucket as Set here, but this is dangerous since the implementation may change over time.
Expected behavior
We should fix this, so we have a happy compiler.
Minimal reproduction of the problem with instructions
Angular >= 12 with TypeScript 4.3.5 and Cashew 2.3.2.
What is the motivation / use case for changing the behavior?
Environment