• W
    (Add tests to) document how multiple inceptors work (#3564) · e6aef5a1
    Wolfram Kriesing 提交于
    * Add a group for the multiple-interceptors tests.
    
    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.
    
    * Fix indentation.
    
    * Make explicit that the test only tests the interception of the fulfilled part.
    
    * Indent.
    
    * Make the test just test a tiny bit, as described.
    
    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.
    
    * Add a test that explicitly shows that the order of interceptors is as they were added.
    
    * Pull out reusable code, to make the tests more explicitly stating the things they care about.
    
    * Write a test showing that the responses are not merged or anything,
    only the last one in the chain is returned.
    
    * Make visible that the interceptors are a chain, one receives its predecessor's data.
    
    * Test what happens when the interceptor throws.
    
    * Refactor, add another group of tests and pull helper function there.
    
    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.
    
    * Documenting that the following reject-interceptor gets called.
    
    * Documenting how the interceptor chain handles caught rejections.
    
    * Document "multiple interceptors".
    
    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.
    
    * Transfer the better readable descriptions as I changed them in the README 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.
    
    * Be a bit more explicit, it was not clear when reading, imho.
    
    * Add new lines to be kinda consistent with the rest of the file.
    Co-authored-by: NJay <jasonsaayman@gmail.com>
    e6aef5a1