You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When writing tests, I like to require explicitly mocking all properties of a mock object that end up getting used by my code. Is there a way for a mock to immediately raise if any property is accessed that has not been mocked via a call to when?
The other thing that irks me about returning null by default is that the mock object may not actually be abiding by it's type, leading to potentially unexpected behavior when writing tests using mocks.
The text was updated successfully, but these errors were encountered:
export class StrictMocker extends Mocker {
protected getEmptyMethodStub(key: string, args: any[]): MethodStub {
return new ThrowErrorMethodStub(-1, [], new Error(`${key} not mocked`));
}
}
// These mimic the overloaded function signature of `mock`
// eslint-disable-next-line @typescript-eslint/ban-types
export function strictMock<T>(clazz: (new (...args: any[]) => T) | (Function & { prototype: T })): T;
export function strictMock<T>(clazz?: any): T;
export function strictMock<T>(clazz?: any): T {
return new StrictMocker(clazz).getMock();
}
For you second point, not sure that this is the correct behavior (you need to specify exactly what output you want to get from mocks with when clauses), and it would introduce a whole new layer of complexity where we would require users of ts-mockito to compile the code with type reflection (so we would know at runtime what type is for each field).
I think if you want an actual mock that contains values that match its type definition, there are other libraries to do so.
When writing tests, I like to require explicitly mocking all properties of a mock object that end up getting used by my code. Is there a way for a mock to immediately raise if any property is accessed that has not been mocked via a call to
when
?The other thing that irks me about returning
null
by default is that the mock object may not actually be abiding by it's type, leading to potentially unexpected behavior when writing tests using mocks.The text was updated successfully, but these errors were encountered: