typestrong / ts-mockito Goto Github PK

In NagRock/issues/212

There is discussion about adding maintainers to the original ts-mockito project.

I still hope the author, NagRock, is able to add maintainers. Barring that, we may want to collaborate on this fork: https://npmjs.com/package/@johanblumenberg/ts-mockito

I also have access to the @TypeStrong org, and we can consider moving the project there.

Other links:

This fork needs passing tests, being discussed in #2

When trying to enable the recommended-type-checked from typescript eslint, I found out that most of ts-mockito argument matchers are actually unsafe since most of them returns any, which completely disables type checking.

An example of a common violated rule when using argument matchers, is no-unsafe-argument

Probably, returning any should be avoided for all argument matchers. Here's a suggestion that I'm evaluating:

export declare function anyOfClass<T>(expectedClass: new (...args: any[]) => T): T;
export declare function anyFunction(): Function;
export declare function anyNumber(): number;
export declare function anyString(): string;
export declare function anything<T>(): T;
export declare function between(min: number, max: number): number;
export declare function deepEqual<T>(expectedValue: T): T;
export declare function notNull<T>(): T;
export declare function strictEqual<T>(expectedValue: T): T;
export declare function match(expectedValue: RegExp | string): string;
type Optional<T, K extends keyof T> = Pick<Partial<T>, K> & Omit<T, K>;
export declare function objectContaining<T extends Object, V extends Optional<T, keyof T>>(expectedValue: V): T;

In the latest version, the package cannot be imported as the "main" and "typings" values of the package.json point to an invalid path. It looks like they're pointing to a lib folder which does not exist in what has been submitted to npm. I can see the lib folder is generated on source compilation but it looks like the project pushes one level lower to npm.

This should either be fixed by changing the package.json to point at the right place, or re-pushing with the lib folder to npm. I will submit a PR for the former but feel free to go with the latter

As mentioned in NagRock#204 it is not possible to use the „instanceof“ operator on an instance of a mock. There are workarounds but the native functionality would be nice.

Example:
const mockedInstanceOfMyClass = instance(mock(MyClass)) console.log(mockedInstanceOfMyClass instanceof MyClass) // false, should be true

It seems like overlapping matchers end up raising an error. It would be helpful if matchers could simply take precedence over each other, e.g. according to the order in which they are specified.

This could allow specifying default (non-null) behavior for a function as well as a different result for specific inputs.

This would make it easy to effectively implement #41 on my own.

Just need to wire the bump command to build ci ..

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.

Hi, I see in npm that the latest version is 2.6.4 but the tags page of the repo just contains v2.6.1.

Where are the release notes and changes of this fork?

Greetings!

I want to mock a standalone function (i.e. a function that's not a method of some object) but I can't find information on that in the readme.

Here is a simplified version of what I'm trying to do:

type Callback = (x: number) => void;

const caller = (callback: Callback) => {
    callback(Math.random())
}

let mockCallback: Callback = mock<Callback>();

caller(mockCallback);            // fails when using mock without instance
caller(instance(mockCallback));  // fails when using mock with instance
caller(x => console.log(x))      // works when not using a mock

As shown above, the first two caller(...) calls that use the mock would fail. They fail with the error:

TypeError: callback is not a function
 ❯ caller src/test.test.ts:7:5
      5|
      6| const caller = (callback: Callback) => {
      7|     callback(Math.random())
       |     ^
      8| }

I want to mock a standalone function so that I can capture its arguments and do stuff with them. Could you please help me out? Thanks

@LironHazan what's your npm username? I'm going to give you publish access to publish @typestrong/ts-mockito

Also, I think you'll need to merge #11 before you do. #11 renames the package from @cspotcode/ to @typestrong/

As a developer I want to set a custom message in a "verify"-command. If the verification fails, I want this message to be displayed (like with expect commands in Chai or with https://github.com/mattphillips/jest-expect-message/tree/main)

@pauleustice

Thinking out load:
With TS 4.4.x following line fails:
service.combinedProviderObservable$.subscribe((value)

TypeError: service.combinedProviderObservable$.subscribe is not a function

I've printed the service for 4.4.x and got:
'**combinedProviderObservable$**': [Function (anonymous)],

And for 4.3.x we get:

     'combinedProviderObservable$': Observable {
        _isScalar: false,
        source: Observable {
          _isScalar: false,
          source: [Observable],
          operator: [CombineLatestOperator]
        },
        operator: MapOperator { project: [Function (anonymous)], thisArg: undefined }
      }

When removing the use of spy it works in 4.4.x,
In TS 4.4.x: When using spy CombineLatest returns a function ref and without the spy the CombineLatest returns an observable.
Won't happen in TS 4.3.x
Wow I don't have a clue,
I'm unfamiliar as well with the spy related code, but what I can do in this repo is adding the test with rxjs that would fail and then we can debug on ts-mockito source

As a developer, I would like to have an in-code-documentation, so that I can read the features and expected behaviours from within the IDE. I would strive for a gradual implementation, so that over the future development the documentation gets progressively better.