add a simple test runner?

An important target group for this app (imo) are beginners and prototype builders. From my experience, both these groups would benefit greatly from having simple test infrastructure bundled with this starter.

From my own experience, I usually have a script.js that I'd include into the main module, but that's pretty hacky until I finally setup (whatever flavor of test infra is popular). The value I get is from being able to write code that'll run on every edit-save separately from my app, but that later morphs into a unit test suite or so on. For beginners, they'd build their app, but write tests for smaller parts of the app they're building, while learning to write tests for their code.

To be clear, I'm not advocating any specific framework/suite/assert libs; I'd just like to be able to run even a if(true) throw new Error script on every change.

Thoughts?

Thanks for the great tool!

I agree we should ship a test runner (Jest, ava, mocha, whatever) as long as we can stick with “no configuration” as the guiding design principle.

Other thoughts:

We’re probably not going to include anything for running tests in browser because of the complexity it involves.
We’re probably not going to include jsdom either.
Testing app logic with a simple Node runner using Jasmine (or what do people use these days?) seems like a good idea.

How about tape? It's super simple and it already almost works -- if you restrict yourself to the subset of ES6 that your version of node supports you can use it now; all one would need to get it working is running it in babel-node; i.e. react-scripts test would run babel-node src/test.js.

With you on zero config; running src/tests.js in a 'watch' mode on npm start (and once on npm run build?) would be good. You sure about not running it in a 'browser' though? Phantomjs works pretty nicely, and wouldn't need any config/ explicit invocation/require iirc.

Huge vote for Mocha + Enzyme + Sinon. This probably requires JSdom, at least according to Enzyme docs.

I'm agree with Threepointone. Maybe PhantomJS with Mocha.

@ffxsam

@ffxsam Enzyme would keep things nice and simple.

Thanks adding it to the conversation!

also headless chrome is round the corner, so that'll be a great solution with no 'dependencies'

I'd be happy to help and/or answer any questions about using Enzyme here!

Is PhantomJS really needed though? It seems a bit overkill, when Enzyme can easily simulate events on components. If I'm not mistaken, PhantomJS & Selenium are more for E2E testing, not unit testing.

@ffxsam

@ffxsam Agree on Enzyme (it's great), and we wouldn't need jsdom if we do shallow rendering.

jsdom is only required for mount and render, correct?

Another vote for Enzyme, simplifies testing considerably, also the official React docs kind of recommend it now 😄

To make it clear, the tool currently only abstracts build dependencies so it shouldn’t matter too much what library you use to make assertions / mount tree / etc. Choosing the runner and conventions is what we need to do.

I'd vote Mocha then

I think what's important here is that we decrease the friction for creating tests as much as possible.

Elixir does this with all new projects and having that passing test ready to go makes me write 10x more tests compared to JS projects because frankly it's chore to get everything setup.

at least as an interim step, we should make sure that the webpack config is enzyme compatible.

Please file an issue if there’s something about that config that breaks enzyme.

I added a PR (#216) to show a basic test setup. I used Mocha, but the most important parts are framework-agnostic, and we should be able to easily swap in another framework if one pulls ahead significantly.

I think what's important here is that we decrease the friction for creating tests as much as possible.

I've gotten a lot of feedback from new React developers that setting up a test environment is a PITA. A production ready test environment that properly deals with CSS/images, mocking/stubbing/spys, shallow rendering, etc. is not a trivial thing to set up and would probably be very beneficial to abstract away.

Elixir does this with all new projects and having that passing test ready to go makes me write 10x more tests compared to JS projects because frankly it's chore to get everything setup.

rails new does this as well. I think an important aspect is to allow users to disable the 'default' test config so they can use their own if they're opinionated.

For example, often in rails projects I pass the -T flag to NOT use minitest and then set up RSpec myself b/c that is the framework I prefer.

Maybe a good compromise is to include the simplest testing setup possible that will be compatible with this project and then allow users to disable instead of enable the testing setup if they decide they want to use a different framework or something more complex. That way people are automatically opted-in to doing something they should be doing (think pit of success) and have to make an active choice to opt out of having a testing environment setup included in their new projects.

@gaearon

@gaearon: @wdhorton already fixed the bug in #216 here.

Jest aaaaalmost works out of the box with create-react-app if you install babel-jest, the only problem is that create-react-app doesn't put a .babelrc file in the root.

@mpj

@mpj Does babel-jest handle non-js imports like import "foo.css" and import "foo.png"?

I am working on the react-scripts run as described by @ForbesLindesay & discussed in #218 . That should be useful for some quick-and-dirty testing and maybe some lighter-weight test frameworks can actually just be invoked through it.

A few people asked me to contribute a pull request with an initial Jest integration: #250

If you'd like to find out more about snapshot testing, please read our new blog post and documentation.

@timjacobi

I'm a big fan of TDD and testing which means I always want it to be easy for people to include tests or to learn more about writing tests.

If a BDD framework such as Mocha or Jasmine were included, it would be nice, however, it is kind of an extra.

I'm thinking back to the first React app I wrote at a Railsbridge (yes, it was Railsbridge, they do js, front-end workshops too). I was wrapping my head around building components and using a store instead of using templates and models. I didn't write any tests. Maybe it's not as important if this is a setup for an initial Hello Components! react app.

Also, there are a lot of opinions that come with testing. The one I see in this thread is folder structure. If I'm encouraging someone to do more testing, they need to be able to arrange their tests in a way that suits them.

My team downloaded create-react-app and found it pretty easy to add tests in a separate test folder. We had to include babel but it was nbd.

I'm with @timjacobi that it seems early to add in testing, but it's not too early for a pointer to anyone who wants to do a test setup. Also I hope people are encouraged to set up tests with this project and it makes me so happy to see this thread!

I'll add my two cents. Contrary to what I expected, it took me just a few minutes to setup mocha, enzyme, expect.js (mostly spent googling, as I had never used any of them).

The inconvenience is that I have two terminal tabs, one for create-react-app, the other for mocha watch. right now, for me this is already good enough; I'm willing to trade a little inconvenience for the ability to ditch, say, mocha for Jasmine whenever I see fit, or to use a single test dir instead of many __tests__ dirs—tastes, as they say.

I'm no beginner, though, and a beginner cannot be expected to know how to hack a testing solution on an existing project, or whether to use Mocha or Jasmine or Karma or whatnot.

So, my proposal:

have exactly one full testing solution nicely integrated (opt out) in create-react-app, with sample tests, pointers to docs, etc.—I have personally no real preferences here, I'm used to Jasmine but I'll use whatever works, they are all very similar after all.
leave room for the integration of alternative solutions—No idea how hard it would be!
have pointers to a few how to docs for other solutions.

This should help beginners to start using React with proper tests without hassle, and should also allow everyone to opt for a different testing setup with reasonable effort.

#250 was merged and should fulfill most of the wishes people expressed in this thread. If you'd like additional features, please feel free to create new issues and cc me on them :)

0.3.0 is out with support for testing.
Read the usage guide and the migration instructions.

💜

Merge pull request react#80 from zinserjan/fix-code-coverage

Navigation Menu

Repository navigation

add a simple test runner? #80

25 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

add a simple test runner? #80

Description

Activity

gaearon commented on Jul 22, 2016

modernserf commented on Jul 22, 2016

threepointone commented on Jul 22, 2016

ffxsam commented on Jul 22, 2016

aaronplanell commented on Jul 22, 2016

selfup commented on Jul 22, 2016

threepointone commented on Jul 22, 2016

aweary commented on Jul 22, 2016

ffxsam commented on Jul 22, 2016

wdhorton commented on Jul 22, 2016

ffxsam commented on Jul 22, 2016

tristanoneil commented on Jul 22, 2016

gaearon commented on Jul 22, 2016

wdhorton commented on Jul 22, 2016

25 remaining items

AdamBrodzinski commented on Jul 25, 2016

gaearon commented on Jul 25, 2016

wdhorton commented on Jul 26, 2016

SpencerCDixon commented on Jul 26, 2016

ariporad commented on Jul 26, 2016

mpj commented on Jul 27, 2016

lacker commented on Jul 27, 2016

cpojer commented on Jul 28, 2016

Marlena commented on Jul 30, 2016

giorgian commented on Jul 30, 2016

cpojer commented on Aug 2, 2016

gaearon commented on Sep 2, 2016

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions