Tests: re-organize and split large files

[jrfnl]

What with the expansion of the test suite over the last few months, a number of test files are becoming quite large and it is not always straight forward anymore to navigate/find what's tested and where.

I'd like to propose to re-organize the test suite along the following lines:

• Each class translates to a subdirectory in the tests directory.
  Classes in subdirectories in src will follow their namespace path first and then have a subdirectory for the class itself.
  Examples:
  • The tests for the WpOrg\Requests\Response class would live in the tests/Response subdirectory.
  • The tests for the WpOrg\Requests\Utility\FilteredIterator class would live in the tests/Utilities/FilteredIterator subdirectory.
• Tests which are testing a class as a whole are put in an ClassNameTest class in this (sub)directory.
• Unit tests for specific methods each get their own test class and file, where the class and file are named after the method being tested.
  For instance, tests specifically for the WpOrg\Requests\Cookie::domain_matches() method would live in a WpOrg\Requests\Tests\Cookie\DomainMatchesTest class.
  For closely linked groups of methods, it is perfectly fine to use one test class, as long as the name of the test class is descriptive.
  Example: tests for array access methods implemented in a class, could be placed in one test class, with the class being called ArrayAccessTest.

When re-organizing the tests along the above lines, I'd also like to propose to order tests in the new classes along the following lines:

• Tests are ordered by the logic order within the method under test.
  For example: if a method under test roughly does: 1) input validation, 2) something conditional 3) something unconditional.
  The tests within the class would be ordered along the same lines, i.e. first the tests for the input validation, then the tests covering the conditional action, then the tests covering the unconditional action.
• Data providers are closely linked to the tests they are used by in two ways:
  1. If the data provider is only used by one test, the name of the data provider should mirror the name of the test method, replacing testwith data, i.e. the testSomething() method would have a data provider called dataSomething().
  2. Method order: the data provider will directly follow the test it is used for. If a data provider is used by multiple test methods, it will follow the last of these methods.
• Test "helper" methods will be placed at the end of a test class and should be named descriptively with regards to their function in the tests.

@schlessera This is roughly what we discussed in one of our calls. Did I miss anything ? Anything else we should consider/create guidelines for before starting this action ?

[jrfnl]

@schlessera Mind looking this over and leaving an opinion ? If we are agreed, I can start getting this set up.

[jrfnl]

@schlessera 👆🏻 When you have a moment ?

[jrfnl]

I've opened up all the follow-up PRs for the individual test class splitting (after the initial move per #705).

Once those PRs have all been merged, this issue should be considered done and closed.

Additional test improvements still needed can then be addressed via #497