Agree that the typical configuration is to have a separate, headless database for running tests.
Your problem sounds similar to (but slightly different from) the problem of running unit-tests provided by extensions. In both cases, one wants to activate the extension on the headless database, so we may borrow some techniques from extension testing.
If I were you, I'd try preparing a DB snapshot with the extension preinstalled, e.g.:
cd ~/buildkit/build/mybuild
# Put the extension source code somewhere under `civicrm`, e.g
git clone https://mygit.example.com/myextension sites/all/modules/civicrm/tools/extensions
# Activate the extension in your main DB, e.g.
drush cvapi extension.install key=com.example.myextension
# Update the DB snapshot for your build
civibuild snapshot mybuild
cd sites/all/modules/civicrm/tools/extensions
# Restore DB & run tests at the same time
civibuild restore mybuild && ./scripts/phpunit CRM_AllTests
Each time you restore the DB, it resets both the main DBs (Civi+CMS) as well as the headless test DB using the latest snapshot.
You can repeat the last command whenever you want to run the tests. This ensures that the extension is active (even if some test went mucking around with extension data).
You can change CRM_AllTests
to api_v3_AllTests
, api_v3_SyntaxConformanceTest
, CRM_Myextension_MyTest
, or any other test class.