Skip to content

Implement bun:test support #247

Closed
Closed

Description

@ceopaludetto

Is there an existing issue for this?

  • I have searched the existing issues

Is your feature request related to a problem? Please describe it

Since bun supports jest.fn I was able to use @automock/jest in my test by supplying jest in global. Working example:

import type { Mock } from "bun:test";

import { beforeAll, describe, expect, it, jest } from "bun:test";
import { TestBed } from "@automock/jest";
import { EntityManager } from "@mikro-orm/postgresql";
import { UserService } from "~/components";

(global as any).jest = jest;

type Mocked<T> = {
	[P in keyof T]: T[P] extends (...args: infer A) => infer R ? Mock<(...args: A) => R> : T[P];
};

describe("UserService", () => {
	let userService!: UserService;
	let entityManager!: Mocked<EntityManager>;

	beforeAll(() => {
		const { unit, unitRef } = TestBed.create(UserService).compile();

		userService = unit;
		entityManager = unitRef.get(EntityManager);
	});

	it("#findAll", () => {
		entityManager.findAndCount.mockResolvedValue([[], 0]);

		expect(userService.findAll({ limit: 10, offset: 0 })).resolves.toEqual([[], 0]);
		expect(entityManager.findAndCount).toHaveBeenCalled();
	});
});

Bun also doesn't have Mocked type by default, so I've created one instead.

Describe the solution you'd like

Provide a @automock/bun which is a copy of @automock/jest but relying on import { jest } from 'bun:test'; instead of global.jest. Also reexport the type Mocked for convenience(I dunno if this type should be recursive).

What is the motivation / use case for changing the behavior?

This library is awesome and bun test runner is fast af. Both combined make NestJS tests enjoyable

Activity

  1. omermorad commented on Jan 11, 2024

    @omermorad
    Collaborator

    Hi @ceopaludetto,

    Thank you :)
    And thanks for posting this.

    Although I haven't personally used Automock with Bun, it's good to know that it can :)
    It sounds like a good idea. It adopts a slightly different strategy, though. Instead of using jest from bun:test, I consider making a new TestBed specifically for Bun, using its mockFn (reference). This is not how users will have to use Jest with Bun.

    Consider it as follows:

    import { beforeAll, describe, expect, it } from "bun:test";
    import { TestBed, Mocked } from "@automock/bun";
    import { EntityManager } from "@mikro-orm/postgresql";
    import { UserService } from "~/components";
    
    describe("UserService", () => {
    	let userService!: UserService;
    	let entityManager!: Mocked<EntityManager>;
    
    	beforeAll(() => {
    		const { unit, unitRef } = TestBed.create(UserService).compile();
    
    		userService = unit;
    		entityManager = unitRef.get(EntityManager);
    	});
    
    	it("#findAll", () => {
    		entityManager.findAndCount.mockResolvedValue([[], 0]);
    
    		expect(userService.findAll({ limit: 10, offset: 0 })).resolves.toEqual([[], 0]);
    		expect(entityManager.findAndCount).toHaveBeenCalled();
    	});
    });

    What do you think?

  2. ceopaludetto commented on Jan 17, 2024

    @ceopaludetto
    Author

    Yeah I've suggested using jest instead of mockFn to be easier to write, since jest package is already written. But using mockFn will be better since it's use bun official mock api.

  3. locked and limited conversation to collaborators on Feb 1, 2024
  4. converted this issue into a discussion #283 on Feb 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions