This ensures that assertions work in a uniform way,
and provides meaningful messages in cause of failure.
Change-Id: Ic01715b9a55444d3df6b5d4097e78cb8ac082b3e
The point of Unit tests is that, among other things, there
is no database
And also some minor cleanup
Change-Id: I8f4a009fe36bf2a2fe79d3261b3b088d25747e20
After approval of RFC T191231, we are going to drop oracle and mssql
and it will be possible to bring back the support using the abstract schema
Adding to release notes will be done in a follow-up
Bug: T230418
Change-Id: I90bd5cfcc3e18011b193c965fdb1fa54675040b5
1. Make sure `wgSQLiteDataDir` is not empty.
2. Fix a logic bug
In the current logic, in web environment, SqliteInstaller::dataDirOKmaybeCreate()
will be executed twice, first in the DBConnect page [1] (with $create=true),
and the second time in Installer::performInstallation() [2] (with $create=false),
this is a sanity check.
But in cli environment, SqliteInstaller::dataDirOKmaybeCreate() will
be only executed once, called by Installer::performInstallation() (with $create=false).
So the Cli installer will abort because the data directory is checked
without the behavior of creating the directory.
In this case, I split dataDirOKmaybeCreate() into checkDataDir() and
createDataDir() according to its responsibility. And for web installation,
we just check the directory on DBConnect page instead of creating it and
then actually creating it in setupDatabase().
3. Add a unit test for SqliteInstaller::dataDirOKmaybeCreate
[1] DBConnect page call SqliteInstaller::submitConnectForm(),
::submitConnectForm() call ::dataDirOKmaybeCreate()
[2] Installer::performInstallation() call SqliteInstaller::setupDatabase(),
::setupDatabase() call ::dataDirOKmaybeCreate()
Bug: T217855
Change-Id: I139036b265716e9898fb76ba907c194f005ea318
This changeset resumes work on T89432 and related tickets
by porting an initial set of tests to the new unit test suite
separated out in I69b92db3e70093570e05cc0a64c7780a278b321a.
The tests were only ported if they worked immediately without
requiring any changes other than changing the test case class
to MediaWikiUnitTestCase and moving the test to the new suite.
If a test failed for any reason (even trivial misconfiguration),
it was NOT ported.
With this change, the unit tests suite now consits of a total
of 455 tests. As before, you can run these tests via the following
command:
$ composer phpunit:unit
Bug: T84948
Bug: T89432
Bug: T87781
Change-Id: Ibb8175981092d7f41864e641cc3c118af70a5c76
This changeset implements T89432 and related tickets and is based on exploration
done at the Prague Hackathon. The goal is to identify tests in MediaWiki core
that can be run without having to install & configure MediaWiki and its dependencies,
and provide a way to execute these tests via the standard phpunit entry point,
allowing for faster development and integration with existing tooling like IDEs.
The initial set of tests that met these criteria were identified using the work Amir did in
I88822667693d9e00ac3d4639c87bc24e5083e5e8. These tests were then moved into a new subdirectory
under phpunit/ and organized into a separate test suite. The environment for this suite
is set up via a PHPUnit bootstrap file without a custom entry point.
You can execute these tests by running:
$ vendor/bin/phpunit -d memory_limit=512M -c tests/phpunit/unit-tests.xml
Bug: T89432
Bug: T87781
Bug: T84948
Change-Id: Iad01033a0548afd4d2a6f2c1ef6fcc9debf72c0d
