Open Electroid opened 1 year ago
ts-jest
does some magical hoisting with mock*
functions which may or may not be a challenge with bun:
https://github.com/swc-project/swc/issues/5448#issuecomment-1386969864
This issue can be updated to check off these four (they were implemented in PR https://github.com/oven-sh/bun/pull/1573):
.toBeGreaterThan(number | bigint)
.toBeGreaterThanOrEqual(number | bigint)
.toBeLessThan(number | bigint)
.toBeLessThanOrEqual(number | bigint)
Should jest.mock
be added as well? Doesn't seem to be tracked.
@erikshestopal please give it a try in the canary build, a lot of it is in there
jest.clearAllMocks()
is also missing 👀 🙏
Would there be any scope to add DOM matchers? If so, I'd love for some parity with the jest-dom library.
toThrowError
is missing. It's a alias for toThrow
.
test.each
and describe.each
are super helpful to build data-driven unit tests.
I am proposing adding https://vitest.dev/api/expect-typeof.html to the vitest list.
test.each
anddescribe.each
are super helpful to build data-driven unit tests.
It's being worked on in PR #4047
Are there plans to add the expect.toBeInTheDocument
matcher from @testing-library/jest-dom
that many typically use for JSX component testing? Or is that out of scope? Feels like that would be something useful to provide out of the box.
expect.objectContaining
any ideas how to replace this call in tests?
expect(Object.fromEntries(data.statistics[Kpi.codes])).toHaveProperty(`502`, 1)
expect(Object.fromEntries(data.statistics[Kpi.codes])).toHaveProperty(`200`, 32)
// instead of:
expect(Object.fromEntries(data.statistics[Kpi.codes])).toStrictEqual(
expect.objectContaining({ '200': 32, '502': 1 })
)
What can you recommend as a replacement for such jest code?
await expect(async () => await askGPT(text, prompt, context)).rejects.toThrowError(`⛔ API error.`)
Shouldn't that be working?
Does this suit your needs?
import { describe, expect, test } from 'bun:test';
const askGPT = async (text: string, prompt: string, context: string): Promise<void> => {
throw new Error('⛔ API error.');
};
describe('', () => {
test('', async () => {
await expect(async () => await askGPT('text', 'prompt', 'context')).toThrow(Error(`⛔ API error.`));
});
});
Edit: these functions have been added to the list, now, thank you!!
Should
jest.mock
be added as well? Doesn't seem to be tracked.
This still seems to not be on the list. Could we get support for jest.mock
and jest.requireActual
compatibility APIs added as an official target on this list? Module mocking is a pretty important part of jest
compatibility.
Example:
import { foo } from 'some-module'
jest.mock('some-module', () => ({
...jest.requireActual<object>('some-module'),
foo: jest.fn(() => 'foo'),
}))
The pattern here allows you to override just the foo
method of some-module
, while requireActual
gives you the real implementation for the rest.
Jest also supports placing an override for some-module
in a __mocks__/some-module.ts
file, as another way to automatically module-mock, though imho that is less priority.
Shouldn't that be working?
Does this suit your needs?
import { describe, expect, test } from 'bun:test'; const askGPT = async (text: string, prompt: string, context: string): Promise<void> => { throw new Error('⛔ API error.'); }; describe('', () => { test('', async () => { await expect(async () => await askGPT('text', 'prompt', 'context')).toThrow(Error(`⛔ API error.`)); }); });
This works only in bun, but not in vitest, so it's not compatible. It seems .rejects.toThrow
is not implemented correctly or at all in bun, it throws Expected value must be a function
on code like this that works in vitest:
await expect(asyncFn()).rejects.toThrow()
There is an issue on spyon https://github.com/oven-sh/bun/issues/4482
Would love to see these implemented:
test.concurrent
test.concurrent.each
test.each
Even basic half-broken implementation of concurrent
(like in jest) would be awesome, as it's absolutely vital for various slow integration tests involving external APIs and services. I'm saying half-broken because in jest before*
and after*
hooks don't work correctly with concurrent
, but it's still usable - you can call the setup/teardown logic directly from each test.
Should
jest.mock
be added as well? Doesn't seem to be tracked.This still seems to not be on the list. Could we get support for
jest.mock
andjest.requireActual
compatibility APIs added as an official target on this list? Module mocking is a pretty important part ofjest
compatibility.Example:
import { foo } from 'some-module' jest.mock('some-module', () => ({ ...jest.requireActual<object>('some-module'), foo: jest.fn(() => 'foo'), }))
The pattern here allows you to override just the
foo
method ofsome-module
, whilerequireActual
gives you the real implementation for the rest.Jest also supports placing an override for
some-module
in a__mocks__/some-module.ts
file, as another way to automatically module-mock, though imho that is less priority.
Well put together @TroyAlford I think this is a very clear implementation maybe you want to create a new issue?
Are there plans to add the
expect.toBeInTheDocument
matcher from@testing-library/jest-dom
that many typically use for JSX component testing? Or is that out of scope? Feels like that would be something useful to provide out of the box.
Very much looking for information on this as well to be honest.
Could we get support for jest.mock and jest.requireActual compatibility APIs
Well put together @TroyAlford I think this is a very clear implementation maybe you want to create a new issue?
This has been added to the list above, now. Thank you!! :) As suggested by @coolxeo, I've also opened a new issue in relation for tracking the sub-task: https://github.com/oven-sh/bun/issues/5394.
Shouldn't that be working? Does this suit your needs?
import { describe, expect, test } from 'bun:test'; const askGPT = async (text: string, prompt: string, context: string): Promise<void> => { throw new Error('⛔ API error.'); }; describe('', () => { test('', async () => { await expect(async () => await askGPT('text', 'prompt', 'context')).toThrow(Error(`⛔ API error.`)); }); });
This works only in bun, but not in vitest, so it's not compatible. It seems
.rejects.toThrow
is not implemented correctly or at all in bun, it throwsExpected value must be a function
on code like this that works in vitest:await expect(asyncFn()).rejects.toThrow()
I have the exact same issue: it is not ISO from jest to bun. expect().rejects.toThrow
breaks in bun while working in Jest.
Shouldn't that be working? Does this suit your needs?
import { describe, expect, test } from 'bun:test'; const askGPT = async (text: string, prompt: string, context: string): Promise<void> => { throw new Error('⛔ API error.'); }; describe('', () => { test('', async () => { await expect(async () => await askGPT('text', 'prompt', 'context')).toThrow(Error(`⛔ API error.`)); }); });
This works only in bun, but not in vitest, so it's not compatible. It seems
.rejects.toThrow
is not implemented correctly or at all in bun, it throwsExpected value must be a function
on code like this that works in vitest:await expect(asyncFn()).rejects.toThrow()
I have the exact same issue: it is not ISO from jest to bun.
expect().rejects.toThrow
breaks in bun while working in Jest.
Same here, it seems like we cannot await on expect
also
Are there plans to add the
expect.toBeInTheDocument
matcher from@testing-library/jest-dom
that many typically use for JSX component testing? Or is that out of scope? Feels like that would be something useful to provide out of the box.
I also need this feature for component testing
Are there plans to add the
expect.toBeInTheDocument
matcher from@testing-library/jest-dom
that many typically use for JSX component testing? Or is that out of scope? Feels like that would be something useful to provide out of the box.I also need this feature for component testing
i've asked a few times on their discord but nobodies been able to give any answer at all regarding this.
@riezahughes we will add support for expect.extend
and get @testing-library/jest-dom
to work
Another thing to consider for compatibility is the ability to configure custom file names to pick up: https://github.com/oven-sh/bun/discussions/5880
In jest you can do this with https://jestjs.io/docs/configuration#testregex-string--arraystring
@Jarred-Sumner @Electroid Hi, is there any roadmap or planned date of release for this missing features? Personally interested in concurrent tests, as it could speed up some tests significantly. By the way do you plan to create some sort of fixtures for tests? I think it is big pain point for a lot of people. Right now we use a workaround, but it would be nice to see it in standard bun testing library. P.S. by fixtures I mean some objects that are reused between tests and there is a ways for tuning its lifetime
@riezahughes we will add support for
expect.extend
and get@testing-library/jest-dom
to work
This is the primary thing keeping us from adopting bun.
@riezahughes we will add support for
expect.extend
and get@testing-library/jest-dom
to workThis is the primary thing keeping us from adopting bun.
This is also the only thing keeping us from adopting bun.
Apart from expect.extend
, these are the ones preventing us to switch to bun test
, since it seems there are no easy workarounds for them:
expect.toHaveBeenCalledWith
, expect.toHaveBeenLastCalledWith
, expect.toHaveBeenNthCalledWith
,
jest.mock
, jest.clearAllMocks
, jest.resetAllMocks
Also, these ones are very helpful to wait for all timers and promises:
jest.runAllTicks
and jest.runAllTimers
Anyway, excellent work! I am using bun
for simple tests and they fly so fast I can't even believe they worked :D
I'm seeing a type problem with expect(x).toSatisfy(predicate). it seems type of x is always unknown.
I think you are missing expect.getState
in your list, which allows to get the current information from the context such as the currentTestName
.
Yeah, I'd love to move to bun but a lot of tests using jest.clearAllMocks
I haven't seen vitest's In-Source Testing mentioned here or documented anywhere else, but I think that would also be a great feature.
Something like
// internal function
const add = (left, right) => left + right
if (import.meta.buntest) {
const { test, expect } = import.meta.buntest
test('add', () => {
expect(add(1,2)).toBe(3)
}
}
and vitest
could be an alias for buntest
which would just expose bun:test
.
The idea is that you can test internal utility functions you don't want to export but that might have decently complicated logic with edge cases worth testing.
Why not track vitest
's expect.unreachable()
? It's very useful for ensuring variables aren't null in strict typescript modes-- i.e., if (!variable) expect.unreachable()
will make sure variable
can't be null
or undefined
going forward.
https://vitest.dev/api/expect.html#expect-unreachable
vitest.dev/api/expect.html#expect-unreachable
That's just an alias for expect.fail
:
if (!variable) expect.unreachable(msg)
is identical to
if (!variable) expect.fail(msg)
Are there any plans to include expectTypeOf
from vitest?
Looks like the expect.extend
box can be checked off now that #7319 is merged, which closed #3621.
Is this accurate? I can't seem to use jest.resetAllMocks()
in the latest version of bun (1.0.15), and I don't see it defined in the types
I don't believe it is, I remember seeing that ticked back as of 1.0.13 and it didn't work then and it still doesn't work now.
Seeing jest.clearAllMocks
checked off but still getting jest.clearAllMocks is not a function
in bun 1.0.17.
Seeing
jest.clearAllMocks
checked off but still gettingjest.clearAllMocks is not a function
in bun 1.0.17.
Same behavior in 1.0.18
@Electroid Could we update the original message with links to GIthub issues discussing the progress of each item that isn't checked off? Even a stub would be useful to follow the progress, i.e. get an email when it's implemented.
The only thing stopping my team from adopting Bun for testing would be having jest.requireActual(module) and .toContainEqual(item).
Plus the following if they indeed don't yet work like posters above mentioned:
The only thing stopping my team from adopting Bun for testing would be having jest.requireActual(module) and .toContainEqual(item).
Just a side note, toContainEqual()
was implemented in v1.0.19 and was highlighted in their release blog post New matcher in bun:test expect().toContainEqual()
When using bun 1.0.21
to explore these examples, I'm also experiencing
8 | jest.advanceTimersByTime(time);
^
TypeError: jest.advanceTimersByTime is not a function. (In 'jest.advanceTimersByTime(time)', 'jest.advanceTimersByTime' is undefined)
When using bun
1.0.21
to explore these examples, I'm also experiencing8 | jest.advanceTimersByTime(time); ^ TypeError: jest.advanceTimersByTime is not a function. (In 'jest.advanceTimersByTime(time)', 'jest.advanceTimersByTime' is undefined)
We haven't implemented Jest timer support in Bun yet
@Jarred-Sumner is missing mock-related functionality (jest.*AllMocks
) a bug or it was incorrectly marked as ready?
Are test reporters in scope for this? eg junit
test reporter can be useful in CI/CD scenarios
The following Jest methods are missing from the checklist:
Jest
describe()
test()
Lifecycle hooks
expect()
Mocks
Misc
Vitest
expect()
Mocks
Timers
Misc
jest-extended
expect()