test-utils
test-utils copied to clipboard
feat: jest enviroment
Resolve #69
Now we can start a test, like this:
/**
* @jest-environment @nuxt/test-utils/environment
* @features server
* @fixture fixtures/basic
*/
import { get } from '../../src'
describe('environment', () => {
test('request page', async () => {
const html = await get('/')
expect(html).toContain('Works!')
})
})
Thanks @mrazauskas for this repo https://github.com/mrazauskas/test-utils-environment-proposal
@pi0 have a problem on listhen
on windows?
https://github.com/nuxt/test-utils/runs/2955816292?check_suite_focus=true#step:8:20
@ricardogobbosouza thanks for mentioning me.
Indeed I was experimenting with Jest environment for some time. Did not send a PR, because the solution did not proof to be useful. On a positive note, I found few solutions how to simplify the code base and to make it more useful. nuxt/test-utils#134 is one of these simplifications / improvements. More on the way.
Back to the the environment. In general it adds two things: pragmas and global variable.
At first I was very excited about pragmas, but how to explain them to the end user? I was trying to draft some docs. On daily basis we write simply JavaScript, not pragmas. They do not look intuitive. Also there is no linting, no auto-completion or any other helpers which we are used to have. Some validation would be nice, but that will add more and more complexity. Is this really useful?
It is nice to look at pragmas, but writing them in each test file felt like programming on a notepad in some exotic language.
Global variable indirectly makes it possible to use test.only
. Really really good. In the other hand, environment setup makes it not possible to spy on nuxt.moduleContainer
. jest.spyOn
is only available after the environment is installed. Some gain, some loss.
So I kept on experimenting with setup. Found a way to keep test.only
working (without adding global variable), to be able to spy on nuxt.moduleContainer
and much more. For instance – nesting of setupTest
with a possibility to extend / override previous config and to roll back after. Very simple solution.
Just trying to explain why I did not send a PR after all the enthusiasm which I wrote about Jest environment.
@mrazauskas It makes sense. I think it would also confuse the user even more. Let's see what @pi0 thinks before closing.
Thanks for sharing your experiences @mrazauskas @ricardogobbosouza and trying it all.
Can we maybe still have an optional jest environment but using this.ctx = createContext
from main utils? (instead of class attributes/methods to duplicate logic) this way we can support both. But no pressure we can do it anytime later.