Hi all, I'm working on a project that will follow DDD with layers and patterns but I also want to use BDD for acceptance testing outside-in.
With this approach, I wondered whether the Behat scenarios would mainly concentrate on the UI? And what the best practices are?
I've read that ideally we don't want to couple scenarios to a UI that could easily change but I'm not sure what the alternative would be when I want to write scenarios in a TDD fashion before any code/layers/patterns exist. I imagine it'd be quite difficult to write scenarios for DDD related code that does not exist yet whereas the UI is more predictable.
click(), but as the DataTables docs say, "The checkbox is not an <input type="checkbox"> element, but rather a CSS that uses the :before and :after pseudo elements of the cell to draw a box and the tick. "
@ciaranmcnulty Would you write steps inside FeatureContext.php using Application services that don't exist yet so that they fail first in the usual TDD fashion? And then start building them to fix the Behat scenarios?
Or with Behat, would the TDD equivalent be writing the scenarios without steps in the FeatureContext.php so that they fail but build the Application services etc before writing the Behat steps?
usleep, as @stof sugested, and wait enough time (lets say, if it usually take 10 sec to do the query and to show the element, you could wait for 30 sec, but that's dirty, it will prove your concept, but dirty). Or you could implement some with
composer require behat/behat --dev, after installation I try
./bin/behatand I get this:
uirapuru@uirapuru-tower:/var/www/new-calendar$ ./vendor/bin/behat In ContainerBuilder.php line 1001: You have requested a non-existent service "cli.output".
uirapuru@uirapuru-tower:/var/www/new-calendar$ php -v PHP 7.2.5-0ubuntu0.18.04.1 (cli) (built: May 9 2018