Open brynwhyman opened 4 years ago
An example where this module would be used: https://github.com/silverstripe/silverstripe-admin/issues/1122
Another way to frame this is "we're able to provide code to support test fixtures specifically for behat / end-to-end tests on a per-module basis"
Providing a separate package that is installed by travis but not require-dev the proposed solution here, which assumes:
So a silverstripe/test-fixtures
module? I feel that if you're writing Behat fixture support or feature support then it's fine for that to live in the module itself (eg. https://github.com/dnadesign/silverstripe-elemental/tree/4/tests/Behat/Context), but we never really had to dive deep into stubbing issues - we were stubbing config, not code.
I don't like the idea of having a module that the Behat tests rely on, but isn't included in require-dev
, as contributors need to be informed of this extra requirement when they cause Behat failures that need to be fixed.
Can't we just ignore tests/behat
in the manifest while we're not serving the project for behat tests? We'll probably have to make some adjustment to https://github.com/silverstripe/silverstripe-framework/blob/4/src/Core/Manifest/ManifestFileFinder.php#L213, but that at least gives more flexibility to the community, and we don't end up with another repo like frameworktest
.
If there are edge cases that the framework allows, I'd say the tests for those should be in the framework's test suite, otherwise, as @ScopeyNZ says, you may break things you don't know about.
I don't like the idea of having a module that the Behat tests rely on, but isn't included in require-dev, as contributors need to be informed of this extra requirement when they cause Behat failures that need to be fixed.
This is a fair point - it should remain possible to run a module's Behat tests locally without manual work (beyond the headache of getting Behat itself working.) Implicitly depending on a module through Travis config would break that assumption.
Overview
Maintainers occasionally come across edge-cases in features where custom code is required to enable writing Behat / functional tests. Adding this code to frameworktest is an option, but that module is littered with a range of code that isn't strictly in service of enabling features for testing purposes. Marking objects as
TestOnly
is also an unsuitable solution for Behat testing.We'd like to look at creating a new module which could hold objects for enabling testing of edge-case features, and other custom code that wouldn't make sense to go into frameworktest.
ACs