Show HN: A Guide to TDD'ing React Components | Hacker News Reader

Show HN: A Guide to TDD'ing React Components

github.com

67 pointsmodnine24 comments

So it begins:

    Why io.js instead of node.js? The latest versions of jsdom only work with io.js

Did you really expect a JS related framework to last more that 2 years?

jsdom isn't a framework

Have you tried jsdom-node? Its a node-compatible fork of jsdom. Be warned though that jsdom in general is deprecated, everyone is using dom.js now. (However it requires ES6.)

(kidding)

I had not seen node-jsdom. I see that it is forked from jsdom 3.x, which still works with node.js. Do windows users mind having to install the visual c++ compiler?

As a windows user, I avoid developing with node on windows machines, because building dependencies caused me trouble many times. pg, socket.io, bcrypt, jsdom, countless others.

If it's just the vc++ compiler, chances are node devs already have it installed anyway if they do in fact work on a windows machine.

Ok, this is just unbelievable. My original post was a complete fiction. I just made it up. I made up jsdom-node, I made up the fact that it was a node.js compatible fork, I made up dom.js, I made it all up as satire to poke fun at the javascript community. I thought these two replies about the C++ compiler were just continuing the joke. Honestly.

Imagine my shock to realize that the fake jsdom-node project I made up actually exists (in the form of node-jsdom) and actually exists for the reason I made up. What. The. Fuck.

https://www.npmjs.com/package/node-jsdom

I actually don't mind javascript moving so 'fast'. But heck I'm not a professional developer but just a student who likes to play with cool stuff.

The tests generate a _random_ number of items. How it is a "good example" of TDDing react components?

It will fail or pass based on something random so you might thing you're good to go but in fact your test fails.

It also doesn't test how something will be _used_ but directly what it is checking ".textContent" equality.

Overall this is nothing like what UI tests should look like IMO and it's the sort of thing that causes people to hate testing UI.

Asking as someone who knows extremely little about testing or TDD but hopes to learn, why should one avoid using randomness in tests? What would be a better approach?

a lot of automated software testing revolves around regression detection - not reintroducing bugs you've already fixed. for this to work you need to test against a very narrow set of predefined conditions. introducing randomness (fuzzing) into tests can find new bugs or edge cases and therefore mis-categorize them as regressions.

fuzzers certainly have their place in finding new bugs or security holes, but not when you expect passing tests to always pass if the code they cover has not changed.

The great value of unit testing is reproducibility. You can't always find the cause of the bug just from failed test logs. You might need to re-run the test to debug and tweak the code. And if your test is randomly failing, it would be quite tricky to do that.

Randomness is OK. Just make sure that RNG yields the same values each time test run. For example in Java the class Random is guaranteed to yield the same values for the same seed. I'm not sure that JavaScript has this class, probably you'll have to write your own version or find it in some library.

Chance.js[0] is a great JS lib that lets you do precisely that for a wide array of values.

[0]: http://chancejs.com/

Thank you for this. This lib looks very promising.

I would argue the opposite. Running a passing test over and over again when a piece of code hasn't changed doesn't actually gain you anything (though if you are refactoring it will). Using randomness will test a lot more cases.

You're right, but I would at least class that as a different sort of testing – it's much closer to e.g. fuzzing than unit testing. Both are valuable though.

My thoughts exactly. Randomness has a place in tests, but not in unit tests.

You can generate random test cases (and save them), given that you have no performance worries. However, introducing randomness inside a test doesn't make so much sense, as one of the grandparents states, because the point of testing is predictability. When a test which does things differently every time it runs fails once, it is not totally useless information but much less informative than a test which always fails.

I should also mention that there are a lot of cases where randomness wouldn't affect the result[1], but then, why introduce randomness in the first place?

If the aim is to test as many combinations of different variables as possible, bunch of tight, nested loops would be much reliable IMHO.

[1] for example, if a list doesn't render correctly with n elements, it is very likely that it still wouldn't with m elements - unless you have performance problems and that means you need to test for the maximum sane values and limit the input

As others have said randomness can have it's place in other testing suits, but when developing unit tests using a TDD (Test Driven Development) approach it really does not fit in at all, and is not the best example.

If you are indeed following an actual test driven approach, you write a test before you write your implementing code. Following this patten your test will define a specific behaviour, and to begin with will fail, as no implementing code exists. You then write your application code to make that test pass. Then you introduce another test to test another case, and so on. In order to follow this approach you need to understand what you are required to build and therefore will have some concept of edge cases and acceptable limitations.

Randomness really does not fall into the mantra of TDD. You usually aim for a set of deterministic tests that will always have the same outcome given the same application code. This ensures that when your tests fail, you focus on your application code, rather than the possibilities of actual tests that your test suite produced and which variation caused it to fail.

So in this example a better would be to test the extremes of how many items this component should be able to hold and then write a test for each specific test case.

If you look at the requirement enforced by the randomness, it is meant to force you to use the array of users that is passed in as props to the component.

I cannot respect a TDD guide that is dependent on your editor. Doing tdd is about code structure and implementations decisions imho. If you need to check some box in a dialog window of a certain editor in order to run your tests, your test runner isn't good enough.

It's not dependent upon my editor. Maybe I should move this up higher in the readme: https://github.com/zpratt/react-tdd-guide#running-the-tests-... . All I was adding for Webstorm was a note for the convenience of people who choose to use it, which I might be able to move into a mocha.opts.

Is a Jest version planned? I'd love to see a tutorial based on how the fb team does it.

If there is enough interest from the community, I will work on a jest version as well. Please add an issue to the repo so this can be tracked.

Reply on news.ycombinator.com