Do we need the function check if we've already proven ABSPATH, or do we need ABSPATH if we're anyway checking for add_action() before running any WP code?

Good point.

ABSPATH prevents processing of the file outside WP env - this is generally useful and in our context stops processing of the file during PHPUnit start procedure, when WP is not yet ready. We want to control the moment this gets loaded.

add_action tests could be considered redundant if ABSPATH is present. Though in WP startup procedure ABSPATH is defined earlier than add_action becomes available. Potentially we can have ABSPATH but no add_action. This just prevents a very "wrong" usage patter from crashing the site.

It's also fine to be extra careful. Let's land this as is, as it won't be included in WP core in the same fashion.

(I'd feel better about skipping abilities-api.php if understood the purpose of all this, but since it's being left out of core, it doesn't actually matter)

This is a test bootstrap. The purpose of this is to circumvent the quirkiness of PHPUnit which automatically loads autoloader, at the very beginning, and thus is triggering the loading of the library. Since it is doing this before WordPress environment has been loaded nothing gets actually loaded ( ABSPATH test prevents it ). Though PHP remembers the require_once calls. If we would load again abilities-api.php nothing would happen, because require_once for bootstrap.php file has been already called. Thus I have made a decision to call it directly for tests once again ( using require to force the load ) - after the WP environment has been loaded. This allows proper loading of all library elements and registering of the filter.

For normal operations from inside WP or a plugin this alterations would not be necessary - this is just for the unit tests and avoids tampering with require_once directives inside the production code which I wanted to avoid.

This one is tricky as autoloader requires the same file, but it doesn't run any logic because of ABSPATH check, so it looks that all is correct.

(@budzanowski yes I understood the what and the how, it's the premise that we should be "triggering the loading of the library" - or more precisely calling that autoloading is now conflated with instantiating the REST endpoint - but still have a separate bootstrap file that confuses me. The architectural implication is that there would be other functionality in ./abilities-api.php now or in the future that we'd no longer be able to test... but again since it's not true IRL it doesn't matter)

@justlevine I agree this could makes things tricky down the road, but I did not wanted to spend too much time anticipating what may be required in the future without actually knowing how this will be used. I bet we will be able to test ./abilities-api.php separately if needed so hopefully this is not limiting.