Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: option to throw instead of returning null for non-mocked properties #41

Open
abel-matsec opened this issue Dec 13, 2023 · 3 comments

Comments

@abel-matsec
Copy link

abel-matsec commented Dec 13, 2023

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.

@abel-matsec
Copy link
Author

Here's a bit of a hack...

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();
}

@roypeled
Copy link
Collaborator

For your first point, I think you can accomplish that with spies, instead of creating a new API:

const objInstance = {} as unknown as MyClass;
const spiedInstance = spy(objInstance);

when(spiedInstance.existingFunction()).thenReturn('foobar');

spiedInstance.existingFunction(); // returns 'foobar'
spiedInstance.nonExistingFunction(); // throws

@roypeled
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants