Change Details

Right now Wikibase Repository, Client, and lib do not separate unit and integration tests, like most of our other components do. Problems: * It is typically not very clear if a test is meant to be an integration or a unit test. * It is not easy to separate the slow tests from the fast or the ones that have no external dependencies from those that do. An added problem results from the first point: people are less likely to pay attention to the difference when writing code or reviewing it. This lack of attention is part of the reason that we have a lot of hard to maintain and understand tests. All PHP tests in repo are current in `tests/phpunit/includes`, with test data being in `tests/phpunit/data`. We could change this to something like `tests/phpunit/unit` for unit tests and `tests/phpunit/integration` for integration tests. The details here are not important to me, as long as we get the clear separation between the two types. We can get very hung up over the exact definition of what a unit and what an integration test is. Having the following criteria for being allowed to put something in the unit test directory will already resolve the mentioned issues and discussion on case by case basis can of course happen. * Can be run without setup further than having PHP and including the PHP dependencies ** Is not affected by configuration (such as MediaWiki config, database config or Wikibase settings) * Does not depend on database, network, disk, caching services, etc. * Does not need to construct non-trivial concrete services that are not part of the unit under test That definition excludes code interacting with global MediaWiki state, such as calling `Title::something`. We might want to also separate this from the real integration tests. That can be done after or while separating out the truly easy to run tests.

Right now Wikibase Repository, Client, and lib do not separate unit and integration tests, like most of our other components do. Problems: * It is typically not very clear if a test is meant to be an integration or a unit test. * It is not easy to separate the slow tests from the fast or the ones that have no external dependencies from those that do. An added problem results from the first point: people are less likely to pay attention to the difference when writing code or reviewing it. This lack of attention is part of the reason that we have a lot of hard to maintain and understand tests. All PHP tests in repo are current in `tests/phpunit/includes`, with test data being in `tests/phpunit/data`. We could change this to something like `tests/phpunit/unit` for unit tests and `tests/phpunit/integration` for integration tests. The details here are not important to me, as long as we get the clear separation between the two types. We can get very hung up over the exact definition of what a unit and what an integration test is. Having the following criteria for being allowed to put something in the unit test directory will already resolve the mentioned issues and discussion on case by case basis can of course happen. * Can be run without setup further than having PHP and including the PHP dependencies ** Is not affected by configuration (such as MediaWiki config, database config or Wikibase settings) * Does not depend on database, network, disk, caching services, etc. * Does not need to construct non-trivial concrete services that are not part of the unit under test That definition excludes code interacting with global MediaWiki state, such as calling `Title::something`. We might want to also separate this from the real integration tests. That can be done after or while separating out the truly easy to run tests. See T87781 for the same taks for mediawiki core.

Right now Wikibase Repository, Client, and lib do not separate unit and integration tests, like most of our other components do. Problems: * It is typically not very clear if a test is meant to be an integration or a unit test. * It is not easy to separate the slow tests from the fast or the ones that have no external dependencies from those that do. An added problem results from the first point: people are less likely to pay attention to the difference when writing code or reviewing it. This lack of attention is part of the reason that we have a lot of hard to maintain and understand tests. All PHP tests in repo are current in `tests/phpunit/includes`, with test data being in `tests/phpunit/data`. We could change this to something like `tests/phpunit/unit` for unit tests and `tests/phpunit/integration` for integration tests. The details here are not important to me, as long as we get the clear separation between the two types. We can get very hung up over the exact definition of what a unit and what an integration test is. Having the following criteria for being allowed to put something in the unit test directory will already resolve the mentioned issues and discussion on case by case basis can of course happen. * Can be run without setup further than having PHP and including the PHP dependencies ** Is not affected by configuration (such as MediaWiki config, database config or Wikibase settings) * Does not depend on database, network, disk, caching services, etc. * Does not need to construct non-trivial concrete services that are not part of the unit under test That definition excludes code interacting with global MediaWiki state, such as calling `Title::something`. We might want to also separate this from the real integration tests. That can be done after or while separating out the truly easy to run tests. See T87781 for the same taks for mediawiki core.