You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Oct 19, 2018. It is now read-only.
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.
The text was updated successfully, but these errors were encountered:
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.
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 freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
The text was updated successfully, but these errors were encountered: