The current test contains a lot of details that are worth being tested
separately and also made explicit. This is what is coming with the next changes.

…led part.

The more explicit the test, the better we can 1) describe what it does
and use that for the docs to make them understandable 2) have a better
explicit description of the API (in case we want to modify it) and 3) have
a regression test when changing.

… they were added.

… things they care about.

only the last one in the chain is returned.

…ecessor's data.

The previous change to also catch in the helper function was not needed
for any of the tests above, so remove it and put it in the describe-block
below where it is needed.
Just trying to write the specific code needed, not more.
Not sure about the impact for failing tests, I am glad about input.
But the main intention here is to have minimal code, explicit tests and
not too much generic code which might break itself eventually.

I just extracted the test descriptions from the new/modified tests.
And I also learned that I should improve the test descriptions, the
tests are just in a GIVEN-WHEN-THEN structure, so I can also use those
terms better. Will do this next.

…ADME back into the tests.

After I had updated the README using the test descriptions I realized how
the test descriptions can be improved, so I did this "moving" the learnings
back into the code.