Running tests in the browser #139

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

Comments

Projects
None yet
@pspeter3

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.

Show comment
Hide comment
@pspeter3

pspeter3 Sep 30, 2014

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

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

@danvk

This comment has been minimized.

Show comment
Hide comment
@danvk

danvk Oct 16, 2014

There was some discussion about this on the mailing list.

danvk commented Oct 16, 2014

There was some discussion about this on the mailing list.

@lostrouter

This comment has been minimized.

Show comment
Hide comment
@lostrouter

lostrouter Jan 3, 2015

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

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

@facundocabrera

This comment has been minimized.

Show comment
Hide comment
@facundocabrera

facundocabrera Jan 21, 2015

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

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

@danvk

This comment has been minimized.

Show comment
Hide comment
@danvk

danvk 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.

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.

Show comment
Hide comment
@pspeter3

pspeter3 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.

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.

Show comment
Hide comment
@facundocabrera

facundocabrera Jan 21, 2015

Thanks a lot for the feedback guys 😄

Thanks a lot for the feedback guys 😄

@leebyron

This comment has been minimized.

Show comment
Hide comment
@leebyron

leebyron Jan 21, 2015

Contributor

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

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.

Show comment
Hide comment
@facundocabrera

facundocabrera 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!

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 in martyjs/marty Feb 21, 2015

Merged

Marty v0.9 #137

50 of 50 tasks complete

@toolness toolness referenced this issue in mozilla/learning.mozilla.org Mar 5, 2015

Merged

Add mocha tests for server/site-generator and browser. #143

3 of 3 tasks complete
@malliapi

This comment has been minimized.

Show comment
Hide comment
@malliapi

malliapi Jun 3, 2015

i would also really appreciate using the specrunner!

malliapi commented Jun 3, 2015

i would also really appreciate using the specrunner!

@mikepc

This comment has been minimized.

Show comment
Hide comment
@mikepc

mikepc 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

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.

Show comment
Hide comment
@kiki-le-singe

kiki-le-singe Aug 4, 2015

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

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

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost 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.

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.

Show comment
Hide comment
@buzinas

buzinas Oct 30, 2015

Any news?

buzinas commented Oct 30, 2015

Any news?

@danvk

This comment has been minimized.

Show comment
Hide comment
@danvk

danvk 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.

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.

Show comment
Hide comment
@QuantumInformation

This comment has been minimized.

Show comment
Hide comment
@QuantumInformation

QuantumInformation 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.

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.

Show comment
Hide comment
@cpojer

cpojer Jan 27, 2016

Contributor

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.

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.

Show comment
Hide comment
@QuantumInformation

QuantumInformation Jan 27, 2016

thanks Chris.

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

thanks Chris.

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

@cpojer

This comment has been minimized.

Show comment
Hide comment
@cpojer

cpojer Jan 27, 2016

Contributor

Seems like that is the same concept?

Contributor

cpojer commented Jan 27, 2016

Seems like that is the same concept?

@QuantumInformation

This comment has been minimized.

Show comment
Hide comment
@QuantumInformation

QuantumInformation Jan 27, 2016

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

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

@QuantumInformation

This comment has been minimized.

Show comment
Hide comment
@QuantumInformation

QuantumInformation 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

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.

Show comment
Hide comment
@cpojer

cpojer Mar 30, 2016

Contributor

Merging this task into #848.

Contributor

cpojer commented Mar 30, 2016

Merging this task into #848.

@cpojer cpojer closed this Mar 30, 2016

@vvo

This comment has been minimized.

Show comment
Hide comment
@vvo

vvo Jun 27, 2016

Contributor

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.

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.

Show comment
Hide comment
@cpojer

cpojer Jun 29, 2016

Contributor

@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.

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.

Show comment
Hide comment
@vvo

vvo Jun 29, 2016

Contributor

Awesome feedback, thanks a lot :)

Contributor

vvo commented Jun 29, 2016

Awesome feedback, thanks a lot :)

@FredyC

This comment has been minimized.

Show comment
Hide comment
@FredyC

FredyC 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.

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.

@Vivihung Vivihung referenced this issue in mmanela/chutzpah Jul 19, 2016

Open

Please add support for Jest #525

@ElGoorf

This comment has been minimized.

Show comment
Hide comment
@ElGoorf

ElGoorf 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?

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.

Show comment
Hide comment
@FezVrasta

FezVrasta 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.

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.

@adborden adborden referenced this issue in 18F/cg-dashboard Jan 17, 2017

Closed

Research/implement unit testing for UI components #948

1 of 1 task complete
@KathiresanRamkumar

This comment has been minimized.

Show comment
Hide comment
@KathiresanRamkumar

KathiresanRamkumar Feb 2, 2017

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

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

@ArmorDarks ArmorDarks referenced this issue in LotusTM/Kotsu Feb 13, 2017

Open

Tests #71

@tajo tajo referenced this issue in cloudflare/cf-ui Feb 17, 2017

Closed

Jest for testing #73

@cyberhck cyberhck referenced this issue in crazyfactory/ts-react-boilerplate May 31, 2017

Merged

test(jest): add jest support #106

@jbalsas jbalsas referenced this issue in metal/gulp-metal Jun 1, 2017

Closed

[FEEDBACK NEEDED] Adds jest test:snapshot task #53

@bvellacott

This comment has been minimized.

Show comment
Hide comment
@bvellacott

bvellacott 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!

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.

Show comment
Hide comment
@FezVrasta

FezVrasta Oct 30, 2017

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

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

@SimenB

This comment has been minimized.

Show comment
Hide comment
@SimenB

SimenB Oct 30, 2017

Collaborator

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

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.

Show comment
Hide comment
@FezVrasta

FezVrasta 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.

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.

@gautamarora gautamarora referenced this issue in CompuIves/codesandbox-client Dec 6, 2017

Closed

Running Unit Tests in CodeSandbox #364

@jonnor jonnor referenced this issue in flowhub/the-graph Dec 27, 2017

Merged

React 15 / Jest #372

@TheSharpieOne TheSharpieOne referenced this issue in Availity/availity-workflow Mar 30, 2018

Closed

Chrome Headless Testing #143

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment