-
Notifications
You must be signed in to change notification settings - Fork 1
Moodle Behat plugin
Moodle includes for us a very useful Behat extenstion that bootstraps the Behat environment onto Moodle. This is great because we don't need to spend time defining our initial feature context, nor mess around with writing a Yaml file.
This plugin is does a lot of work behind the scenes. Let's try to shed some light on the inner workings.
Behat tests need clean slate whenever you run them. This is to prevent fragments of a previously run test affecting the next one. For example, a test can create users and enroll them in courses. Suppose your next test requires an empty course? You can either try to run your tests in a specific order, or try to manually un-enroll them before the next test. This sounds like a lot of work and a lot of book keeping. Here's where the Moodle plugin kicks in.
When you run the Behat init script, Moodle creates a duplicate set of tables. These tables are differentiated with a prefix mdl
for our standard moodle tables, and bht
for Behat tables. The duplicate set of tables are the ones that Behat writes to in order to preserve the state of a test. The tables will be created with a minimal amount of data to run a Moodle instance, so they won't contain duplicate data.
Every time you run a new Behat scenario, the bht
tables are reset to their initial state, and the new test will write to new tables. The major implication here is that you cannot rely on shared data between scenarios. The other thing is that this reset step is expensive. Perhaps not so noticeable when you're running a single test, but if you run a suite of tests, expect to wait a while.
Note that scenarios only reset the bht
tables. The process of duplicating the tables is reserved for two scenarios
- You are setting up the environment for the first time.
- The code you are testing initiates a Moodle upgrade (basically a version file is incremented).