I'm adding a new answer because my perspective is different from when I wrote the original question and answer; it doesn't make sense to mesh them together into one.
I said in the original question
However, I can't see anything wrong with my design (how else do you generate a list of data objects, some of whose values are depended on where in the sequence they are?—can't exactly generate and test them separately)
This is where I went wrong. After doing functional programming for the last year, I now realize that I just needed a collection operation with an accumulator. Then I could write my function as a pure function that operated on one thing and use some standard library function to apply it to the collection.
So my new answer is: use functional programming techniques and you will avoid this problem entirely most of the time. You can write your functions to operate on single things and only apply them to collections of things at the last moment. But if they are pure you can test them without reference to collections.
For more complex logic, lean on property-based tests. When they do have logic, it should be less than and inverse to the logic of the code under test, and each test verifies so much more than a case-based unit test that the small amount of logic is worth it.
Above all always lean on your types. Get the strongest types you can and use them to your advantage. This will reduce the number of tests you have to write in the first place.