-
Notifications
You must be signed in to change notification settings - Fork 360
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. Weβll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Extract fixtures into separate classes #234
Conversation
Codecov Report
@@ Coverage Diff @@
## main #234 +/- ##
=========================================
Coverage 58.07% 58.07%
Complexity 2044 2044
=========================================
Files 315 315
Lines 5104 5104
=========================================
Hits 2964 2964
Misses 2140 2140 Continue to review full report at Codecov.
|
7eeee89
to
86ebdd0
Compare
I like this PR. Does it make sense to leave all/most of the current code as is, and then when we move to extensions, we just copy the tests we like. Eventually we remove the legacy tests. |
Yeah agree on the approach |
@localheinz will you make a first setup of this or should some of us support you with anything here? |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed after 1 week if no further activity occurs. Thank you for your contributions. |
Needs a review! π€ |
Looks fine. Advantage is that we are actually following psr-4 now... :P |
Lgtm |
Thank you, @GrahamCampbell, @Nyholm, and @pimjansen! |
This PR
πββοΈ There is a range of test classes in
tests/Faker
. Some of the files declare additional classes in the containing files.The first impulse would be to move them into separate files, declaring a single class in each file. The question that arises then is: where to put these classes?
We use
Faker\Test
as namespace for tests. We couldFaker\Test\Double
Faker\Test\Fixture
Faker\Test\Integration
Faker\Test\Unit
This could nicely map to the following directory structure:
However, we currently autoload classes from the
Faker\Test
namespace using a PSR-4 autoloader with PSR-0 class mapping with the following directory structure:We could move classes into the following structure:
but then these classes would mix with existing classes.
We could move existing classes from
test/Faker/
totest/
, effectively flattening the directory structure. People often complain that this will make history hard to understand or follow (I don't care much). Since a lot of classes will be removed or extracted into separate packages, these tests will disappear sooner or later, too.That's why I propose to keep the old tests and add new tests in a separate structure:
We could then easily differentiate between kinds of tests, in particular, tests that demonstrate the behaviour from the outside as expected from users (also see #233), and others, that test specifics of extensions and similar.
Eventually, we could remove the directory
test/Faker
.What do you think?