Front end developer specialising in JavaScript and React. Experienced in all aspects of modern front end development. Passionate about making accessible, secure and performant software.
I agree with most of it. I agree with you that Jest isn't really meant for DOM tests except for basic cases. I also agree that it doesn't play well with mocking ES Modules.
I overcome the mocking of modules by parameterising things. I tend to pass stuff in as arguments instead of hardcoding imports. I think it's a good method for clean code as well as testability. I also think it's fine for some "integration tests" in cases where you're dealing with things that must be mocked, such as dates or databases. Generally, I prefer "dependency injection" to "monkey-patching".
When I need to test the logic of stuff that needs rendering, I use JSDOM. It can be messy sometimes, as you suggested. So it seems like your method of using web-test-runner could be a great alternative for this. I'll give it a go in my own projects.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Good article, thanks.
I agree with most of it. I agree with you that Jest isn't really meant for DOM tests except for basic cases. I also agree that it doesn't play well with mocking ES Modules.
I overcome the mocking of modules by parameterising things. I tend to pass stuff in as arguments instead of hardcoding imports. I think it's a good method for clean code as well as testability. I also think it's fine for some "integration tests" in cases where you're dealing with things that must be mocked, such as dates or databases. Generally, I prefer "dependency injection" to "monkey-patching".
When I need to test the logic of stuff that needs rendering, I use JSDOM. It can be messy sometimes, as you suggested. So it seems like your method of using web-test-runner could be a great alternative for this. I'll give it a go in my own projects.