Testing Chapter

[bebraw]

I'm gathering some ideas for the testing chapter here. I'll cover at least:

• Jest - There's no nice loader for Jest yet. jest-webpack is relevant, though.
• mocha-loader - Mocha should be much faster than Jest and it works with React too after some tweaking
• Coverage testing
• rewire
• tap and tape
• substack on testing

Other ideas?

[christianalfoni]

I use jasmine, and jasmine-node. Hooking up with jsdom etc. Fast and nice :-)

[bebraw]

@christianalfoni Any particular thoughts on testing Baobab?

[christianalfoni]

Hi @bebraw !

Hm, have not really tested Baobab. Not sure what strategy is best here. Test actions against Baobab, test fetching of state to the components. Hm hm... I would suggest that the critical part is "Does your actions update the tree correctly?". Grabbing the state in the components kinda "just works", as long as it is defined correctly.

A challenge though is that the actions usually depend on the tree as an external module. Gives some challenges when testing.

[bebraw]

Yeah, based on what I've seen so far components get quite entangled with Baobab. I have a feeling that might need some abstraction. Ie. keep components as simple and pure as possible and push Baobab binding to some other level. Not sure yet.

I need to research React testing strategies on a more general level. I have a feeling you could take some ideas from Selenium (ie. test recording) and adapt those to React level (write test scenarios easily in browser itself?). In the end it comes down to what you want to assert and what's worth testing.

Testing itself is a complex topics as there are so many levels in it. You can approach it from a very high level (map user stories and requirements to tests) or from a very low level (test that an individual component works in a sane way etc.). Then there are concepts like fuzzing, mutation testing, coverage and so on. Lots of potential things to discuss.

[christianalfoni]

Yeah, testing is definitely a complex subject. Personally I like to build up my code so that business logic can be easily unit tested (pure functions) and my components are also pure, so they are easily tested with React TestUtils. But that is all in theory ;-)

[dmitry]

I'm really interested in how to do an integration / acceptance testing of a pages, especially when API is outsourced.

• Is it a good idea to test with sinon.js or https://github.com/algolia/faux-jax?
• Should I test API request/response (it would be good to have it, in other case tests might become outdated and nobody will notice).?
• And what about server/client rendering - should be those two isomorphic/univeral enitities tested differently?

With react it's very easy to test for a design changes, like https://github.com/cburgmer/csscritic does. I haven't found an integration of similar tool with react, but if you know some - it would be nice to know.

[bebraw]

@dmitry Speaking of acceptance testing in particular you may find Protractor useful. It is a tool aimed specifically for Angular and it wraps Selenium with a much saner API. Fortunately it is possible to use it with React as illustrated by an article by Joel Auterson. Perhaps that will come in handy.

Testing React is still in flux but it looks like some solutions are fortunately appearing. Here are a couple of other articles to study:

• http://nicolasgallagher.com/how-to-test-react-components-karma-webpack/
• https://www.codementor.io/reactjs/tutorial/test-reactjs-components-karma-webpack
• http://kentor.me/posts/testing-react-and-flux-applications-with-karma-and-webpack/

[Foxandxss]

Mocha should work good for testing React. Mocha + Karma + code coverage. That should be a good way to test React.

[chiefjester]

interesting talk: https://medium.com/javascript-scene/why-i-use-tape-instead-of-mocha-so-should-you-6aa105d8eaf4

[fgarcia]

It might be controversial using a tool from other language, but I love testing my apps with Capybara+PhantomJS

Once I go for acceptance testing, I hate using mocks and just script everything in the most language/framework independent way against a real staging server. Maybe it is just a matter of taste being a Ruby a dev, but I find the feature DSL syntax of capybara much nicer than one can get with tools like Casper

On the other hand, I do love using mocks, but I only if they are kept at a minimum. I am still trying to find out other types of testing with plain Javascript

[Foxandxss]

As an ex-ruby developer I see your idea Francisco. Ruby after all pushed the testing all the way forward and capybara is awesomesauce.

Now, as a book author (and this book editor), I don't like the idea.

For me, a book should be as generic as possible, because the readers don't want to learn the author particular quirks nor his uncommon framework picks.

When you read a book, let say to learn Rails, you normally want to learn about well, Rails, ActiveRecord and the common picks for testing. You normally won't like if the author decided to use a third party ORM that is not that common because he likes it. Yes, you will learn lot of things, but you probably won't use that ORM and you would prefer to learn ActiveRecord.

So my point is: Teach as standard and generic as possible and once you learn how it is commonly done, you can learn other tools if you want to, to see if that feed your needs.

Well, worst is when the author creates his own ORM and decides to use that on a book. Please, don't do that :P

[bebraw]

There's a testing chapter now. Leanpub folks get early access, the rest TLDR;. ;)