When writing tests it would be helpful to use the test classes to run against an installation of Drupal created by means other than the test setup. When writing functional tests and integration tests for whole-site builds and not specific features isolated to specific modules, the approach to writing tests has typically been:
Alternatives to this are writing the site as an installation profile that can be used for each test or importing the websites configuration folder during every test run. The issue with these two approaches is how slow they are and missing out on creating a test environment that exactly represents production, beyond just the configuration and code.
Examples of things which impact a site during runtime are the sites content, all configuration created/available for modification on production and the database schema (a site having gone through every updb as opposed to a fresh module installation). Once an environment is replicated on CI, tests of this kind are impacted by these factors, making them useful for determining the real status of a site.
Add a property to BrowserTestBase which forgoes the installation of Drupal, sets the test class up to run against the parent site and cleans up entities created during the test.
None.
Additional properly on BTB that controls the Drupal installation status.
None.
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
Moshe did not get a lot of traction and archived the repo. back in 2018. More up to date activity here. Re-opening.
The project moved to Gitlab -> https://gitlab.com/weitzman/drupal-test-traits