Skip to content
This repository has been archived by the owner on Oct 19, 2018. It is now read-only.

build react test renderer capybara driver #7

Open
sfcgeorge opened this issue Dec 4, 2017 · 2 comments
Open

build react test renderer capybara driver #7

sfcgeorge opened this issue Dec 4, 2017 · 2 comments

Comments

@sfcgeorge
Copy link

React provides a Test Renderer that renders into pure JS - doesn't need a full browser and doesn't even need JSDom. This would make for the fastest most reliable tests, a really nice proposition.

Due to its limited nature it's only really unit tests, not full acceptance tests. This could be a good option to have - we could have 2 Capybara drivers for use with Hyper Spec, one for unit testing Hyperloop components, and one for fuller acceptance tests. See #6 for a list of options.

I reckon an interface to the React Test Renderer could actually be built as a Capybara driver using mini_racer. A lot of the Capybara DSL wouldn't have a 1 to 1 mapping, but it may still be possible to massage a subset into working.

I'd like to try #6 first as I think JSDom would be the easiest driver to write, with the most flexible balance of speed and functionality. Plus it would work for other JavaScript tests in your app, not just Hyperloop stuff.

@catmando
Copy link
Contributor

catmando commented Dec 4, 2017

See other comments on #6, but I would like debate this a little philosophically with you if you don't mind.

The hyperloop philosophy is that the application is unified, and the client/server boundary is made as transparent as possible. Thus you might have a component like OrdersIndex that displays a formatted list of orders, with some params controlling the scope. In a "pure" hyperloop App OrdersIndex is directly accessing AR models and displaying them to some spec. So the Unit Test for OrdersIndex IMO is to to set up via factory girls some orders, and make sure things are rendered correctly.

I understand this is a change from normal client code testing where unit testing means "in isolation from the server" and "acceptance testing" means integrated with the server.

In Hyperloop it is still a unit test because the component is not integrated with the other peices of the UI, and the AR records are being created specifically for this test in isolation. The acceptance testing with then be the full system being loaded, and the component being just part of the overall page.

Would be interested on your thoughts on this

@sfcgeorge
Copy link
Author

If this driver couldn't be built in such a way that it still works with Hyper Model and FactoryBot, then I agree it would be giving up too much to be of any use. I'm not sure if it's possible or not so this issue is more of an idea thread.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants