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?
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.
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
[0]: http://chancejs.com/
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.
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.