We introduced a handful of test fixtures in #319 (basically the files make:reset-password generates) so we can run tests against a "real" symfony webapp. This is great, but maintaining fixtures is not ideal. We should:
- Remove the fixtures (or atlease as many as we can)
- call
make:reset-password right after we call make:user in the functional test
- run tests against the generated code
The reason why this was not done in #319 - make:reset-password requires user input to successfully execute. To simulate that in a test, we need to:
- Create a "test" process
- stream the contents of an array of user input e.g.
['question 1 input', 'question 2 input']
- execute the test process to run the test
We do this in MakerBundle -> https://github.com/symfony/maker-bundle/blob/main/src/Test/MakerTestEnvironment.php#L333 But that code is internal (and should stay that way for now).
Ideally, we would have a symfonycasts/test-helpers repo (insert better name here) that is "internal" / doesnt provide BC guarantees, etc.. that we can use in reset-password, verify-email, etc... to handle the nuts and bolts of bootstrapping a "app" test.
We introduced a handful of test fixtures in #319 (basically the files
make:reset-passwordgenerates) so we can run tests against a "real" symfony webapp. This is great, but maintaining fixtures is not ideal. We should:make:reset-passwordright after we callmake:userin the functional testThe reason why this was not done in #319 -
make:reset-passwordrequires user input to successfully execute. To simulate that in a test, we need to:['question 1 input', 'question 2 input']We do this in MakerBundle -> https://github.com/symfony/maker-bundle/blob/main/src/Test/MakerTestEnvironment.php#L333 But that code is internal (and should stay that way for now).
Ideally, we would have a
symfonycasts/test-helpersrepo (insert better name here) that is "internal" / doesnt provide BC guarantees, etc.. that we can use in reset-password, verify-email, etc... to handle the nuts and bolts of bootstrapping a "app" test.