This creates a dedicated test suite for integration tests. All of them
can be run independently, and there is no order dependency - previously,
all integration tests needed the installer test to run first, and they
would fail if installation failed.
Now, the developer will have to set up a Flarum database to be used by
these tests. A setup script to make this simple will be added in the
next commit.
Small tradeoff: the installer is NOT tested in our test suite anymore,
only implicitly through the setup script. If we decide that this is a
problem, we can still set up separate, dedicated installer tests which
should probably test the web installer.
Since this is not strictly speaking a domain invariant, but rather
specific to the user interface where passwords are not displayed, and
should therefore be entered twice to prevent mistakes going unnoticed,
this stuff should be checked in the frontend, not in the install steps.
Next step: Ensure that all domain-specific validation is done in the
installer's domain layer. This will ensure these validations cannot be
forgotten, and keep the frontends DRY.
Since we do not provide a development VM anymore, it does not make sense
to have "default" credentials etc.
To reproduce something similar, I'd suggest using a YAML or JSON file
together with the `--file` option.
We are still testing the installation logic, but not testing the
actual CLI task. I would love to do that, but IMO we first need to
find a way to do this fully from the outside, by invoking and
talking to the installer through the shell.
Because acceptance tests are easier to do when fully decoupled from
the application. (After all, they are intended to save us from
breaking things when changing code; and we cannot prove that when
we change the tests at the same time.)
It might be easier to start with acceptance tests for the web
installer, though.
This is probably the most complicated way I could find to fix#1587.
Jokes aside, this was done with a few goals in mind:
- Reduce coupling between the installer and the rest of Flarum's
"Application", which we are building during installation.
- Move the installer logic to several smaller classes, which can then
be used by the web frontend and the console task, instead of the
former hacking its way into the latter to be "DRY".
- Separate installer infrastructure (the "pipeline", with the ability
to revert steps upon failure) from the actual steps being taken.
The problem was conceptual, and would certainly re-occur in a similar
fashion if we wouldn't tackle it at its roots.
It is fixed now, because we no longer use the ExtensionManager for
enabling extensions, but instead duplicate some of its logic. That is
fine because we don't want to do everything it does, e.g. omit
extenders' lifecycle hooks (which depend on the Application instance
being complete).
> for each desired change, make the change easy (warning: this may be
> hard), then make the easy change
- Kent Beck, https://twitter.com/kentbeck/status/250733358307500032Fixes#1587.
This is important because extensions may wish to render post content
differently depending on Request factors such as the actor. For example,
an attachments extension might wish to hide attachments from guests.
This solution is a bit of a hack-job for now, but soon when we refactor
the API layer to use tobscure/json-api-server, and also refactor the
Formatter layer, it can be revised.
