8/11/2023 0 Comments Drupal pathauto![]() So most of our steps start with Given I am logged in as a user with the role "foo" because we're testing functionality on the behalf of a particular user, and this in turn uses DrupalContext::createUser(), which uses user_save(), which in turn invokes hook_user_insert() ![]() => Behat\Behat\Console\BehatApplication::doRun => Symfony\Component\Console\Application::doRun => Symfony\Component\Console\Application::doRunCommand => Symfony\Component\Console\Command\Command::run => Behat\Behat\Console\Command\BehatCommand::execute => Behat\Behat\Console\Command\BehatCommand::runFeatures => Behat\Behat\Tester\FeatureTester::visit => Behat\Behat\Tester\OutlineTester::visit => Behat\Behat\Tester\OutlineTester::visitOutlineExample => Behat\Behat\Tester\ScenarioTester::visitStep => Behat\Gherkin\Node\AbstractNode::accept ![]() => Behat\Behat\Tester\StepTester::executeStep => Behat\Behat\Tester\StepTester::executeStepDefinition => Behat\Behat\Definition\Annotation\Definition::run => Drupal\DrupalExtension\Context\DrupalContext::assertAuthenticatedByRole => Drupal\Driver\DrupalDriver::userCreate => Drupal\Driver\Cores\Drupal7::userCreate We re-ran our tests using phing and saw this trace right where things started going astray. So knowing that menu_rebuild() is the function that does the rebuild and that it lives in includes/menu.inc, we opened up the file and hacked in some code to print the backtrace when the function was called. But it was clear that something else was triggering a menu rebuild during our test suite. It does a chdir() to the Drupal root first, then resets the working directory afterwards. Now the DrupalExtension knows this, and if you use the 'and the cache has been cleared' the step definition it provides in DrupalContext is aware of this. It was clear that something was triggering a menu rebuild and because we run Behat using phing from outside the Drupal root, we weren't getting all of the necessary include files loaded, particularly those include files that defined the default page manager variants. Now this is one of those times and another one of those reasons where contributing to core makes you more knowledgeable and your day-job just that little bit easier :-).īecause of our familiarity with core, we were able to diagnose the issue straight away. ![]() We knew for certain that the front page wasn't a 404, but that's what Behat was telling us, and if we visited the home-page immediately after running the tests it in fact was a 404.Īs soon as we cleared the cache - we got the home page back. Our project scaffold includes a basic Behat feature to check that the home-page returns a 200 Ok response, for this project it too was a page manager page and even it was failing. Using this we could see that the standard node page view was being used instead of our page manager variant. The problem was easily diagnosable by adding: And then show last response Our tests would pass fine for the first few steps, then after a particular point in the test suite, every path that used a page-manager page would fail. So what was our problem? Well testing manually, functionality worked just fine, but testing with Behat would net weird results. So with that in place you can access Drupal API's in your custom step definitions. The $ placeholders are populated from our build.properties file using a phing build target so each developer can specify their local environment settings, such as the URL to their dev site, and the directory it lives in. In order to use the Drupal Driver you need to configure your behat.yml to nominate the api_driver. This means we have access to the full Drupal API's in our step definitions and any content changes that are made as part of the tests can be cleaned up in the after scenario method. In order to make these step definitions as flexible as possible, we're using the DrupalDriver on some of our projects instead of the BlackBox or DrushDriver. ![]() So because we want to adapt our tests to the natural language of the acceptance criteria, rather than the other way around, we are regularly adding to our FeatureContext class to define the custom step definitions. This has the advantage that our tests are already written when we start the story. It lets you write human-readable stories that describe the behaviour of your application, that can be automatically executed to test if it's working as expected.įor some of our projects, we've embraced Behat so much that we've taken to writing the acceptance criteria for our stories in the Given, When, Then format. In case you hadn't heard of it before, Behat is a PHP testing framework for Behaviour Driven Development. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |