If you're getting fatal errors due to missing, required files, there's a good chance that you're running into the issue described here: https://www.previousnext.com.au/blog/using-behat-and-drupaldriver-bewar…

In short, a menu rebuild is being called from outside of the Drupal root, thereby exploding your registry. For me, this was caused by views_content_cache, which calls views_invalidate_cache() and triggers a menu rebuild after certain entity operations. Here's how I got around that.

In your featureContext.php file's __construct() function, add:

<?php
global $_behat_is_running;
$_behat_is_running = TRUE;
?>

You can now use this global variable in your custom modules to determine if Behat is running.

Now let's add some logic to a custom module. Given that calls to views_invalidate_cache() are the main issue, let's hook into that function call and prevent the disastrous menu rebuild from occurring.

<?php

/**
 * Implements hook_views_invalidate_cache().
 */
function grasmash_views_invalidate_cache() {
  global $_behat_is_running;
  if ($_behat_is_running) {
    // views_invalidate_cache() has triggered a menu rebuild at this point.
    // We need to prevent a standard menu rebuild during a Behat run, because
    // it will explode the registry. We do this by rebuilding it ourselves first
    // in a manner that mocks Drupal7::clearCache().
    // @see https://www.previousnext.com.au/blog/using-behat-and-drupaldriver-beware-pathauto
    grasmash_rebuild_menu();
    watchdog('grasmash', 'Rebuilding menu.');
  }
}

/**
 * Rebuild menu from the correct directory.
 *
 * Need to change into the Drupal root directory or the registry explodes.
 */
function grasmash_rebuild_menu() {
  $current_path = getcwd();
  chdir(DRUPAL_ROOT);
  menu_rebuild();
  chdir($current_path);
}
?>