New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Running tests in the browser #139

Closed
pspeter3 opened this Issue Sep 30, 2014 · 37 comments

Comments

Projects
None yet
@pspeter3
Copy link

pspeter3 commented Sep 30, 2014

It would be great for a TDD setup to be able to run the tests in the browser and see the component you are trying to test. Is it possible to run jest in the browser?

@pspeter3

This comment has been minimized.

Copy link
Author

pspeter3 commented Sep 30, 2014

Specifically I just want the ability to run a single jest test file

@danvk

This comment has been minimized.

Copy link

danvk commented Oct 16, 2014

There was some discussion about this on the mailing list.

@lostrouter

This comment has been minimized.

Copy link

lostrouter commented Jan 3, 2015

is there a way that jest could make use of the jasmine spec runner?

@facundocabrera

This comment has been minimized.

Copy link

facundocabrera commented Jan 21, 2015

Anyone has any update on this? Is there any work in progress?

@danvk

This comment has been minimized.

Copy link

danvk commented Jan 21, 2015

We migrated our tests to Mocha for this reason, among others. I'd highly recommend doing the same (or to Jasmine). While we still can't run our tests in-browser (they depend on fs and other node modules that don't make sense there), we can at least use node-inspector, which is almost as good for debugging.

@pspeter3

This comment has been minimized.

Copy link
Author

pspeter3 commented Jan 21, 2015

We migrated our tests to mocha as well. We use browserify to run them in the browser and jsdom to run them on the command line.

@facundocabrera

This comment has been minimized.

Copy link

facundocabrera commented Jan 21, 2015

Thanks a lot for the feedback guys 😄

@leebyron

This comment has been minimized.

Copy link
Contributor

leebyron commented Jan 21, 2015

Nothing done here yet, as the auto-mocking requires the node runtime environment.

@facundocabrera

This comment has been minimized.

Copy link

facundocabrera commented Jan 22, 2015

Why do not provide a working version without auto-mocking? I remember https://remysharp.com/2014/05/30/commonjs-with-devtools-live-edit so it should not be impossible to do this limited version.

I know PR are welcome!

@dariocravero dariocravero referenced this issue Feb 21, 2015

Merged

Marty v0.9 #137

50 of 50 tasks complete
@malliapi

This comment has been minimized.

Copy link

malliapi commented Jun 3, 2015

i would also really appreciate using the specrunner!

@mikepc

This comment has been minimized.

Copy link

mikepc commented Jul 24, 2015

The important issue here is the ability to use the browser to debug the unit test in the browser. It's very useful to debug the code you're testing, rather than a run-and-see-if-it-works setup. Really helps in a TDD environment

@kiki-le-singe

This comment has been minimized.

Copy link

kiki-le-singe commented Aug 4, 2015

if there is no possibility to test in browsers, how can we debug?

@ghost

This comment has been minimized.

Copy link

ghost commented Aug 5, 2015

Thank you for reporting this issue and appreciate your patience. We've notified the core team for an update on this issue. We're looking for a response within the next 30 days or the issue may be closed.

@buzinas

This comment has been minimized.

Copy link

buzinas commented Oct 30, 2015

Any news?

@danvk

This comment has been minimized.

Copy link

danvk commented Oct 30, 2015

It's a truism: if you're going to run your code in the browser then you should test it in the browser, too. Running your tests under node with jsdom isn't the same thing. It's just going to give you headaches.

My preferred approach for testing client-side JS is currently Mocha + mocha-phantomjs for running tests on the command line, but there are many ways to do it.

@QuantumInformation

This comment has been minimized.

Copy link

QuantumInformation commented Jan 25, 2016

+1

@QuantumInformation

This comment has been minimized.

Copy link

QuantumInformation commented Jan 26, 2016

So is there no simple way to run jest (using jasmine 2) through karma? What is so difficult about it if Jasmine already can? Seems like a MVP requirement for any test runner for unit testing enterprise apps.

@cpojer

This comment has been minimized.

Copy link
Contributor

cpojer commented Jan 27, 2016

Oh I haven't commented here. The new architecture of jest proposed in #599 will make it easier to build a server environment around Jest. This is unfortunately not a priority for Facebook however, so I'm not going to actively push for this. If anyone wants to work on it, I'd be happy to help.

@QuantumInformation

This comment has been minimized.

Copy link

QuantumInformation commented Jan 27, 2016

thanks Chris.

What about running Jest on node webkit and chromimum web driver?

@cpojer

This comment has been minimized.

Copy link
Contributor

cpojer commented Jan 27, 2016

Seems like that is the same concept?

@QuantumInformation

This comment has been minimized.

Copy link

QuantumInformation commented Jan 27, 2016

Yeah I guess so. I'll see what I can dig up on it.

@QuantumInformation

This comment has been minimized.

Copy link

QuantumInformation commented Jan 27, 2016

I tried just running in the browser with jest like so:

https://github.com/QuantumInformation/JestBrowserTest

but I get this error in the console:

Uncaught (in promise) SyntaxError: Unexpected token H

@cpojer

This comment has been minimized.

Copy link
Contributor

cpojer commented Mar 30, 2016

Merging this task into #848.

@cpojer cpojer closed this Mar 30, 2016

@vvo

This comment has been minimized.

Copy link
Contributor

vvo commented Jun 27, 2016

One very interesting information from this thread is that it seems running unit tests in browsers not to be a priority for Facebook. Which means: Facebook, one of the biggest website in the world does not need to run unit testing in browsers, only in nodejs, with jsdom and auto mocks.

Could maybe one Facebook engineer explain how they came with this reasoning. Is facebook using solely jest for unit testing of their components base?

As for me I believe most important bugs nowadays will come from your own coding, not because of a bug in a browser.

Unit testing in node with mocks should be sufficient to test the flow of your program. Once you are able to mock any browser quirk then you can mock it in nodejs. If you need to test that your login form is working in latest chrome then it's a job for selenium and a whole different subject.

@cpojer

This comment has been minimized.

Copy link
Contributor

cpojer commented Jun 29, 2016

@vvo Hey! I'm happy to share some thoughts. Five years ago we actually used to have a browser unit test suite (that I used to work on, hah!) but it wasn't good, slow to use and not how people built code at FB.

We then built a command line testing utility with a mock-dom and people loved the iteration speed and how well it worked. The browser test suite was killed and we never looked back. To cover browser testing we do a lot of things ranging from web driver tests, manual QA and especially employee dogfooding. These things have in general provided more value than a flaky browser test engine that is hard to scale for thousands of tests.

However, I do recognize that people enjoy writing tests using a browser environment. Node's debugging story is getting a lot better and JS frameworks provide the necessary abstractions to take care of this. There is an ongoing conversation about the potential of Jest running in the browser some day: #848.

@vvo

This comment has been minimized.

Copy link
Contributor

vvo commented Jun 29, 2016

Awesome feedback, thanks a lot :)

@FredyC

This comment has been minimized.

Copy link

FredyC commented Jun 29, 2016

I'll just add my two cents here. I've started working on a new project with React. I've decided to write unit tests for my Redux code only. Instead of browser tests I am giving a go to shiny new toy called React Storybook which essentially allows me to create show case (story) of my components and how would they behave/render based on various inputs. What I like most about it is the way how it forces you to create decoupled small components. You have to think about that single component only when designing it.

Of course it cannot be compared to webdriver tests as it's not automated in any way. Also it's harder to imagine using it for a huge project like Facebook with hundreds of components. On other hand you have a nice "catalog" of available components and you can immediately see its use cases. It is probably gonna be even bigger beast once https://storybooks.io/ is ready. And who knows, perhaps one it will be automated some way too, eg. comparing changes and validating it hasn't changed from last time.

@ElGoorf

This comment has been minimized.

Copy link

ElGoorf commented Dec 18, 2016

One reason I'd like in browser testing is browsers handle JS Proxy while babel doesn't. does anyone have an advice for the meanwhile?

@FezVrasta

This comment has been minimized.

Copy link

FezVrasta commented Jan 9, 2017

My use case for browsers support is to be able that a library I created interacts correctly with different browsers and versions. Right now I have to use Karma + Jasmine, but Jest would be much easier to manage.

@KathiresanRamkumar

This comment has been minimized.

Copy link

KathiresanRamkumar commented Feb 2, 2017

How to run a case multiple times multiple source files jest?@cpojer

@bvellacott

This comment has been minimized.

Copy link

bvellacott commented Sep 29, 2017

I don't see how jest is faster and stabler than running browser tests. It starts up as long as the dev build does, so would a browser test build start up any longer. Debugging with node-debug is much slower and with a browser setup, debugging would be a given. Also setting up shims and webpack requireContexts is useless with jest, because everything you get working with webpack, you then need to get working in a node environment which then produces redundant switch code or massive linting issues etc... Its a pain!

@FezVrasta

This comment has been minimized.

Copy link

FezVrasta commented Oct 30, 2017

Are there updates on this now that Jest supports custom runners?

@SimenB

This comment has been minimized.

Copy link
Collaborator

SimenB commented Oct 30, 2017

You can use mocha (or jasmine) and karma to run jest assertions (and mocks) in the browser.

See #848 for a tracking issue to run Jest itself in the browser

@FezVrasta

This comment has been minimized.

Copy link

FezVrasta commented Oct 30, 2017

Yeah ok but I think the point is to use Jest.

I was wondering if now that we are able to write custom runners for Jest, this could have been made possible by a 3rd party runner.

@mhuggins

This comment has been minimized.

Copy link

mhuggins commented Sep 2, 2018

I was just bitten by this. I have a test passing in Jest, but the behavior is different in the browser. This is specifically because the URL object does not match between these two environments.

https://stackoverflow.com/questions/52141486/testing-url-usage-for-browser-in-node-js

@stockenja

This comment has been minimized.

Copy link

stockenja commented Nov 27, 2018

It's a truism: if you're going to run your code in the browser then you should test it in the browser, too. Running your tests under node with jsdom isn't the same thing. It's just going to give you headaches.

My preferred approach for testing client-side JS is currently Mocha + mocha-phantomjs for running tests on the command line, but there are many ways to do it.

So, true! So much pain to do something simple like testing ES6 code in a browser environment.

FACEBOOK, please just make a Facebook browser. A browser that would run ES6 code instead of the whole transpile BS. It is time for Javascript to mature and have a real solid standard.

The browser will be good for your stock price too. Trust me! If you make a Facebook browser, I will go buy your stocks immediately.

Yao from Stockenja

@brucou

This comment has been minimized.

Copy link

brucou commented Nov 27, 2018

Can't agree more with running tests in a real browser. I use good old Qunit and react-testing-library for my react code. Does not work too badly, but more importantly I avoid the quirks related of browser reimplementations. I don't avoid the quirks of React DOM though... And I loose snapshots. Oh well...
My main reason, apart from I already mentioned, was that it is much more convenient to debug in the browser, and then because I actually play a sequence of inputs in the browser, I can see what is being displayed at what time on a real screen, that is invaluable on some bugs. I don't how much time is lost running the test in the browser but I do believe a lot of time is also saved by finding bugs quicker instead of playing detective around browser abstractions. In any case, for the sanity of my mind, that is a much better solution

@AndyOGo AndyOGo referenced this issue Jan 17, 2019

Open

integrate jest #775

6 of 10 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment