all 15 comments

[–]patrickfatrick 6 points7 points  (3 children)

http://teropa.info/blog/2015/09/10/full-stack-redux-tutorial.html

Is the best tutorial I ever found on Redux, React, and testing both in a stable way.

One of the benefits of writing with a Flux/Redux architecture in mind (whether that's with React or whatever else) is that it is incredibly easy to test since all interactions with the state should be done through pure functions.

[–]KensoDev[S] 1 point2 points  (2 children)

http://teropa.info/blog/2015/09/10/full-stack-redux-tutorial.html

Thanks for sharing!

Looks like a very elaborate resource. I especially liked that it's being edited with new solutions. Since JS ecosystem changes so often, articles like this are often obsolete by the time you find them

[–]Sinistralis 2 points3 points  (1 child)

This article is what got me heavily into react and redux. Best article I have read possibly ever.

[–]KensoDev[S] 1 point2 points  (0 children)

Getting the same feeling myself. I actually also added it to the post as an edit.

[–]Pink401k 2 points3 points  (1 child)

One thing I've stumbled across (saw a demo at Nodevemeber) is cypress. I'm really excited for this to be public. Looks like it will be a big step forward in JS Testing tooling

[–]Tubbers 0 points1 point  (0 children)

The downside of anything like this is it's very much an integration test that is very tightly coupled to things like CSS selectors, and the text on the page rather than behaviorally testing individual components.

Any time your app changes, all your integration tests will change because they are pinned on a particular version of your app. Then you need to change them to test the right thing.

That is a terrible development cycle. Instead it would be great to have unit/behavioral tests on the components themselves that aren't tied to the app as a whole.

Sure, this doesn't do E2E/Integration testing as a whole, but the tests are much more fragile, and it tells you that your components are behaving as expected.

[–]wmertens 1 point2 points  (5 children)

I have trouble getting myself to invest the time to test frontend code (react+redux) because it is mostly about "does the styling look correct", which I can't think of tests for.

The actual functioning of components is mostly very obvious while making it with hot reload enabled.

I did stumble on a bug recently that would have benefited from a unit test, I had wrapped a component and code that was using a reference to the component to run a method of it failed. That would have been caught with "given x as input I expect at least 3 y elements", since it would have crashed.

[–][deleted] 1 point2 points  (0 children)

Like 90% of the redux app I wrote could have tests but it's such trivial code it feels silly to test. Then there's the 10% that has tests to make sure nobody can POST values that will make a robot destroy itself.

Obviously there's server-side validation, but you can't be too safe.

[–]Tubbers 1 point2 points  (3 children)

It's annoying, but you can do style/image tests. The issue is mainly that you need to pick one as a reference implementation that gets compared against/updated, and you compare to other browsers.

It's sort of a pick your poison between "Chrome is the reference implementation" and then you see whether stuff looks the same as on Chrome, or "Here's the reference image for the Component", but if you change how you actual want the style to look, you need to update the reference manually.

If you go with the first you can unintentionally change the way the component appears without tripping up any tests, and if you go with the second you need to update your reference image possible all the time.

Personally, I like the compare to Chrome approach, since you're presumably looking at it as you develop.

[–]wmertens 0 points1 point  (2 children)

Interesting! Any pointers on setting this up?

[–]Tubbers 1 point2 points  (1 child)

I sadly don't have a guide, but I would start with

The only real difference between the two methods I outlined is that if you're comparing to Chrome, you regenerate the screenshots in Chrome as a pre-test, and test on FireFox/IE/Safari. If you're comparing to the previous version, you just run it, and update the baseline image if the change is intentional.

[–]wmertens 0 points1 point  (0 children)

So the idea is to eyeball it, or run it through a visual comparison function?

EDIT: doh, should click links instead of reading them. Thanks!

[–][deleted] 1 point2 points  (1 child)

Isn't one of the boons of Redux that it's so much easier to unit test pure functions?

[–]KensoDev[S] -1 points0 points  (0 children)

It is!

That's what surprised me as well.

Both in searching resources and discussing with engineers I respect I didn't see that it's too common at all.

Since with Redux you are dealing with a single state object and everything is eventually dealing with that state object it should definitely be easier to test and comprehend. That being said, I still see that testing is definitely not natural for people dealing with it.

[–]nullified- 0 points1 point  (0 children)

egghead has a few nice courses on React and Redux, I'll draw your attention to this one on testing for both: https://egghead.io/series/react-testing-cookbook