Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

Acceptance testing for the Moodle App: Difference between revisions

From MoodleDocs
Moodle App

Upgrade from previous versions:

For user documentation see Moodle Mobile

m (Update categories)
(Update migration status and path)
 
(9 intermediate revisions by 4 users not shown)
Line 1: Line 1:
{{Template:Migrated|newDocId=/general/app/development/testing/acceptance-testing}}
{{Moodle App (Ionic 5)}}
{{Moodle App (Ionic 5)}}
In order to run tests that carry out automated functionality testing for the Moodle App, you can write [[Acceptance testing|Acceptance tests]]. This can be useful if you want to test plugins that are compatible with the app, or you're contributing to the app core. Behat tests for the app work the same way as tests for Moodle core, but they are not run as part of a normal Behat execution and there are some differences that we'll go through in this page.
In order to run tests that carry out automated functionality testing for the Moodle App, you can write [[Acceptance testing|Acceptance tests]]. This can be useful if you want to test plugins that are compatible with the app, or you're contributing to the app core. Behat tests for the app work the same way as tests for Moodle core, but they are not run as part of a normal Behat execution and there are some differences that we'll go through in this page.


Line 6: Line 6:


The main advantages of this approach are:
The main advantages of this approach are:
* It is easy for third-party plugin authors to create tests for app features in exactly the same way that they create tests for website features.
* It is easy for third-party plugin authors to create tests for app features in exactly the same way that they create tests for website features.
* Where institutions run tests automatically, it should be relatively easy to include some app tests within the existing approach.
* Where institutions run tests automatically, it should be relatively easy to include some app tests within the existing approach.
Line 13: Line 12:


== Installation ==
== Installation ==
In order to run tests for the app, you will need to run both a Moodle site and the Moodle App.
In order to run tests for the app, you will need to run both a Moodle site and the Moodle App.


Line 21: Line 19:


Nevertheless, if you still have to run the projects in your local machine, you can read the following instructions.
Nevertheless, if you still have to run the projects in your local machine, you can read the following instructions.
=== Configuring the Moodle site ===
=== Configuring the Moodle site ===
You can learn how to run a Moodle site locally in [[Setting up development environment]].
You can learn how to run a Moodle site locally in [[Setting up development environment]].


Remember to install the [https://github.com/moodlehq/moodle-local_moodlemobileapp/ local_moodlemobileapp] plugin with the same version that you're using for the mobile app.
Remember to install the [https://github.com/moodlehq/moodle-local_moodlemobileapp/ local_moodlemobileapp] plugin with the same version that you're using for the mobile app.
=== Configuring the Moodle App ===
=== Configuring the Moodle App ===
If you are going to modify the application code, you can learn how to run it locally in [[Setting up your development environment for the Moodle App]]. You only need to run the application in a browser, so you can skip the instructions for Android/iOS. Make sure to launch the application on the testing environment, running <code>npm run serve:test</code>.
If you are going to modify the application code, you can learn how to run it locally in [[Setting up your development environment for the Moodle App]]. You only need to run the application in a browser, so you can skip the instructions for Android/iOS. Make sure to launch the application on the testing environment, running <code>npm run serve:test</code>.


Line 35: Line 29:


However you set up the environment, if you change the version of the app you'll need to re-run the Behat init command so that your Moodle site knows about it.
However you set up the environment, if you change the version of the app you'll need to re-run the Behat init command so that your Moodle site knows about it.
=== Configuring Behat ===
=== Configuring Behat ===
In order to enable app testing, you need to add the following configuration to your site's <code>config.php</code> file:
In order to enable app testing, you need to add the following configuration to your site's <code>config.php</code> file:
<syntaxhighlight lang="php">
<syntaxhighlight lang="php">
$CFG->behat_ionic_wwwroot = 'http://localhost:8100';
$CFG->behat_ionic_wwwroot = 'http://localhost:8100';
</syntaxhighlight>
</syntaxhighlight>
 
The url you use here must be reachable by your Moodle site, and the application needs to be served at this url when running tests and also when you initialise the Behat environment.
The url you use here must be reachable by your Moodle site, and the application needs to be served at this url when running tests and also when you initialize the Behat environment.


The Moodle App [[Using the Moodle App in a browser|only works in Chromium-based browsers]], so mobile tests will be ignored if you are using any other browser. You can learn how to configure the browser used in your tests in the [[Running acceptance test]] page.
The Moodle App [[Using the Moodle App in a browser|only works in Chromium-based browsers]], so mobile tests will be ignored if you are using any other browser. You can learn how to configure the browser used in your tests in the [[Running acceptance test]] page.


If everything is configured properly, you should see "Configured app tests for version X.X.X" after running <code>admin/tool/behat/cli/init.php</code>.
If everything is configured properly, you should see "Configured app tests for version X.X.X" after running <code>admin/tool/behat/cli/init.php</code>.
== Running Behat ==
== Running Behat ==
To run mobile tests in Behat, simply launch Behat in the usual way. The app tests all have the <code>@app</code> tag, so if you want to run all the mobile tests you can use <code>--tags=@app</code>.
To run mobile tests in Behat, simply launch Behat in the usual way. The app tests all have the <code>@app</code> tag, so if you want to run all the mobile tests you can use <code>--tags=@app</code>.


It is OK to combine mobile and web tests in the same run.
It is OK to combine mobile and web tests in the same run.
== Writing tests ==
== Writing tests ==
This page assumes you already know all about [[Writing acceptance tests]] in general.
This page assumes you already know all about [[Writing acceptance tests]] in general.
=== Test structure ===
=== Test structure ===
Mobile app test scenarios should be marked <code>@app</code> and <code>@javascript</code> in addition to any other tags.
Mobile app test scenarios should be marked <code>@app</code> and <code>@javascript</code> in addition to any other tags.


You are writing a normal Behat test and this is likely to require background steps, such as creating courses, users, groups, etc.
You are writing a normal Behat test and this is likely to require background steps, such as creating courses, users, groups, etc.
=== Start the app ===
=== Start the app ===
When you want to get started testing the application, you can use the following step to launch the application:
When you want to get started testing the application, you can use the following step to launch the application:
<syntaxhighlight lang="gherkin">
<syntaxhighlight lang="gherkin">
Given I enter the app
Given I enter the app
</syntaxhighlight>
</syntaxhighlight>
This will:
This will:
* Set up all the Moodle server settings to allow the Moodle App to connect.
* Set up all the Moodle server settings to allow the Moodle App to connect.
* Restart the browser, this is needed to ensure that it doesn't use data from previous runs.
* Restart the browser, this is needed to ensure that it doesn't use data from previous runs.
Line 87: Line 66:


You can also use this step if you are already using the app and it will restart it.
You can also use this step if you are already using the app and it will restart it.
=== Log in to the app ===
=== Log in to the app ===
To log in, you can use the following step:
To log in, you can use the following step:
<syntaxhighlight lang="gherkin">
<syntaxhighlight lang="gherkin">
When I log in as "student"
When I log in as "student"
</syntaxhighlight>
</syntaxhighlight>
This is the same step that's used to log into standard Moodle, and it works in the app as well. You should have created the user in background steps, and it will log in using the text as both username and password.
This is the same step that's used to log into standard Moodle, and it works in the app as well. You should have created the user in background steps, and it will log in using the text as both username and password.


You will then be left at the start page.
You will then be left at the start page.
=== Standard steps ===
=== Standard steps ===
Technically, you can use any standard Behat action in the app. However, most of them will probably not work as you expect because the app runs on a different environment. It is still a website, but it's built using [https://ionicframework.com/docs/ Ionic Framework].
Technically, you can use any standard Behat action in the app. However, most of them will probably not work as you expect because the app runs on a different environment. It is still a website, but it's built using [https://ionicframework.com/docs/ Ionic Framework].


Line 111: Line 84:


Having said that, here's a list of steps that work and you can use reliably.
Having said that, here's a list of steps that work and you can use reliably.
* Any step you normally need to set up information in Moodle — For example, creating courses, users, etc.
* Any step you normally need to set up information in Moodle — For example, creating courses, users, etc.
* <code>I change viewport size to "{width}x{height}"</code> — You can use this step to simulate switching between portrait and landscape formats.
* <code>I change viewport size to "{width}x{height}"</code> — You can use this step to simulate switching between portrait and landscape formats.
* <code>I pause</code> — This step works and it is very useful to debug your scenario.
* <code>I pause</code> — This step works and it is very useful to debug your scenario.
=== Actions ===
=== Actions ===
<syntaxhighlight lang="gherkin">
<syntaxhighlight lang="gherkin">
When I press "Course 1" in the app
When I press "Course 1" in the app
</syntaxhighlight>
</syntaxhighlight>
 
This will click an element found using accessibility rules, so it could be visible text, content inside <code>aria-label</code>, content described by <code>ara-labelledby</code>, etc. It should work for links, buttons and other clickable elements.  
This will click an element found using acessibility rules, so it could be visible text, content inside <code>aria-label</code>, content described by <code>ara-labelledby</code>, etc. It should work for links, buttons and other clickable elements.  
 
<syntaxhighlight lang="gherkin">
<syntaxhighlight lang="gherkin">
When I press "Course 1" near "Unique text" in the app
When I press "Course 1" near "Unique text" in the app
</syntaxhighlight>
</syntaxhighlight>
You can use this step to narrow matches if the text you're providing is duplicated throughout the page.
You can use this step to narrow matches if the text you're providing is duplicated throughout the page.


Line 133: Line 100:


Nearest is defined in terms of the DOM rather than pixel position; it is based on the number of steps you would have to take up the tree from the candidate element before you get to a shared ancestor with the unique text.
Nearest is defined in terms of the DOM rather than pixel position; it is based on the number of steps you would have to take up the tree from the candidate element before you get to a shared ancestor with the unique text.
<syntaxhighlight lang="gherkin">
<syntaxhighlight lang="gherkin">
When I select "Item 1" in the app
When I select "Item 1" in the app
Line 140: Line 106:
When I unselect "Item 1" near "Unique text" in the app
When I unselect "Item 1" near "Unique text" in the app
</syntaxhighlight>
</syntaxhighlight>
You can use these steps to select or unselect radio buttons, check boxes, and such.
You can use these steps to select or unselect radio buttons, check boxes, and such.


You could use the previous <code>I press</code> step as well, but in some cases you will notice that it doesn't work as you expect. This is due to some internal quirks of how Ionic renders these components, so prefer using this specific steps where possible.
You could use the previous <code>I press</code> step as well, but in some cases you will notice that it doesn't work as you expect. This is due to some internal quirks of how Ionic renders these components, so prefer using this specific steps where possible.
<syntaxhighlight lang="gherkin">
<syntaxhighlight lang="gherkin">
When I set the field "field name" to "text value" in the app
When I set the field "field name" to "text value" in the app
When I set the field "field name" near "Unique text" to "text value" in the app
When I set the field "field name" near "Unique text" to "text value" in the app
</syntaxhighlight>
</syntaxhighlight>
This sets a text field with the given value. The same rules will apply to find the input element as for clicking, so using the input name will not suffice. This is in order to encourage accessibility best practices. The only difference with the previous step is that this only matches fillable elements such as <code><input></code>, <code><textarea></code> and elements with <code>contenteditable="true"</code>.
This sets a text field with the given value. The same rules will apply to find the input element as for clicking, so using the input name will not suffice. This is in order to encourage accessibility best practices. The only difference with the previous step is that this only matches fillable elements such as <code><input></code>, <code><textarea></code> and elements with <code>contenteditable="true"</code>.
<syntaxhighlight lang="gherkin">
<syntaxhighlight lang="gherkin">
When I press the back button in the app
When I press the back button in the app
When I press the main menu button in the app
When I press the more menu button in the app
When I press the page menu button in the app
When I press the page menu button in the app
When I press the user menu button in the app
</syntaxhighlight>
</syntaxhighlight>
These steps will press, respectively:
These steps will press, respectively:
 
* The '''back button''' — This is the left pointing arrow at top left of the app.
* The back button — This is the left pointing arrow at top left of the app.
* The '''more menu''' button — This is the icon with at bottom right of the app.
* The main menu button — This is the icon with at bottom right of the app.
* The '''page menu''' button, if present — This is the icon with the three dots at top right of the app.
* The page menu button, if present — This is the icon with the three dots at top right of the app.
* The '''user menu''' button, if present — This is the avatar button at top right of the app present on navigation level 1.




Line 169: Line 131:
When I close the browser tab opened by the app
When I close the browser tab opened by the app
</syntaxhighlight>
</syntaxhighlight>
These two steps are necessary if you want to test the transition between the app and a browser.
These two steps are necessary if you want to test the transition between the app and a browser.


For example, after pressing "Open in browser" you can use the first step above, and you will be able to use normal Moodle Behat steps to work in the browser tab. Once you're finished, you can use the second step to go back to the app.
For example, after pressing "Open in browser" you can use the first step above, and you will be able to use normal Moodle Behat steps to work in the browser tab. Once you're finished, you can use the second step to go back to the app.
=== Assertions ===
=== Assertions ===
Like actions, there are some Behat assertions that are specific to the app.
Like actions, there are some Behat assertions that are specific to the app.
<syntaxhighlight lang="gherkin">
<syntaxhighlight lang="gherkin">
Then I should find "Course 1" in the app
Then I should find "Course 1" in the app
Line 184: Line 142:
Then I should not find "Course 1" near "Unique text" in the app
Then I should not find "Course 1" near "Unique text" in the app
</syntaxhighlight>
</syntaxhighlight>
These steps can be used to assert that the specified text exists somewhere in the app.
These steps can be used to assert that the specified text exists somewhere in the app.


Notice that the standard <code>I should see</code> step may not work in the app because of the Shadow DOM. This step will also search using accessibility rules, so text within <code>aria-label</code> or described with <code>aria-labelledby</code> will work as well.
Notice that the standard <code>I should see</code> step may not work in the app because of the Shadow DOM. This step will also search using accessibility rules, so text within <code>aria-label</code> or described with <code>aria-labelledby</code> will work as well.
<syntaxhighlight lang="gherkin">
<syntaxhighlight lang="gherkin">
Then the header should be "Course 1" in the app
Then the header should be "Course 1" in the app
</syntaxhighlight>
</syntaxhighlight>
This checks the text of the current page header. It must be an exact match for the specified text.
This checks the text of the current page header. It must be an exact match for the specified text.


You could have used the <code>I should find</code> step described previously, but this allows you to specifically check the header as opposed to anything in the page.
You could have used the <code>I should find</code> step described previously, but this allows you to specifically check the header as opposed to anything in the page.
<syntaxhighlight lang="gherkin">
<syntaxhighlight lang="gherkin">
Then "Item 1" should be selected in the app
Then "Item 1" should be selected in the app
Line 203: Line 157:
Then "Item 1" near "Unique text" should not be selected in the app
Then "Item 1" near "Unique text" should not be selected in the app
</syntaxhighlight>
</syntaxhighlight>
You can use these steps to assert whether radio buttons, check boxes, and such are selected or not.
You can use these steps to assert whether radio buttons, check boxes, and such are selected or not.
=== Leaving the app ===
=== Leaving the app ===
If you want to leave the app and go back to Moodle within a scenario, simply use a Moodle step that goes to a page. For example, use <code>I am on site homepage</code> or <code>I am on "Course 1" course homepage</code>.
If you want to leave the app and go back to Moodle within a scenario, simply use a Moodle step that goes to a page. For example, use <code>I am on site homepage</code> or <code>I am on "Course 1" course homepage</code>.


You only need to do this if you want to carry out actions within Moodle after using the app, within the scenario. At the end of your scenario, there is no need to explicitly leave the app; Moodle will automatically start the next scenario on the Moodle start page as usual.
You only need to do this if you want to carry out actions within Moodle after using the app, within the scenario. At the end of your scenario, there is no need to explicitly leave the app; Moodle will automatically start the next scenario on the Moodle start page as usual.
=== A complete example ===
=== A complete example ===
This example is a complete feature file that loads the app, opens a course, and asserts that the app is showing the course page:
This example is a complete feature file that loads the app, opens a course, and asserts that the app is showing the course page:
<syntaxhighlight lang="gherkin">
<syntaxhighlight lang="gherkin">
@app @javascript
@app @javascript
Line 240: Line 188:
     Then the header should be "Course 1" in the app
     Then the header should be "Course 1" in the app
</syntaxhighlight>
</syntaxhighlight>
You can find more complex examples looking at the [https://github.com/moodlehq/moodle-local_moodlemobileapp tests for the app core].
You can find more complex examples looking at the [https://github.com/moodlehq/moodle-local_moodlemobileapp tests for the app core].
== Limitations ==
== Limitations ==
Using this approach, there are some limitations you should be aware of:
Using this approach, there are some limitations you should be aware of:
* Lack of native functionality — Fundamentally, it is not possible to test behaviour specific to native devices because tests are run in a browser.
* Lack of native functionality — Fundamentally, it is not possible to test behaviour specific to native devices because tests are run in a browser.
* Missing functionality — There are some known limitations and unsupported features, for example there is currently no obvious way to attach files. Some of these are possible, but they haven't been implemented yet. If something is missing for your use-case, you can submit feature requests in [https://tracker.moodle.org/browse/MOBILE the tracker] using the <code>Behat</code> component.
* Missing functionality — There are some known limitations and unsupported features, for example there is currently no obvious way to attach files. Some of these are possible, but they haven't been implemented yet. If something is missing for your use-case, you can submit feature requests in [https://tracker.moodle.org/browse/MOBILE the tracker] using the <code>Behat</code> component.
== Advanced ==
== Advanced ==
=== Versioning ===
=== Versioning ===
Behat tests can relate to particular versions of the mobile app. For these situations, there are two types of tags you can add to your scenario or feature:
Behat tests can relate to particular versions of the mobile app. For these situations, there are two types of tags you can add to your scenario or feature:
* <code>@app_from{version}</code> — These will be included in every app matching the specified version and newer.
* <code>@app_from{version}</code> — These will be included in every app matching the specified version and newer.
* <code>@app_upto{version}</code> — These will be included in every app matching the specified version and older.
* <code>@app_upto{version}</code> — These will be included in every app matching the specified version and older.
Line 262: Line 202:
You can use two-digit or three-digit version numbers. For example, you could use <code>@app_from4.0</code> or <code>@app_upto3.9.5</code>.
You can use two-digit or three-digit version numbers. For example, you could use <code>@app_from4.0</code> or <code>@app_upto3.9.5</code>.


After changing the app version used for testing, make sure you re-run Behat init. It is the initialization process that stores which version of the app you're using.
After changing the app version used for testing, make sure you re-run Behat init. It is the initialisation process that stores which version of the app you're using.
 
=== Testing against multiple app versions ===
=== Testing against multiple app versions ===
If you need to run tests against multiple versions of the app, you can do it in two ways:
If you need to run tests against multiple versions of the app, you can do it in two ways:
# Update the code in the app workspace by checking out a different version.
# Update the code in the app workspace by checking out a different version.
# Maintain multiple copies of the mobile app workspace and switch between them by changing <code>config.php</code>.
# Maintain multiple copies of the mobile app workspace and switch between them by changing <code>config.php</code>.
Line 275: Line 212:


Unfortunately, the only way to run this in parallel is to have separate Moodle installations with their own configurations.
Unfortunately, the only way to run this in parallel is to have separate Moodle installations with their own configurations.
=== Debugging tests ===
=== Debugging tests ===
If you insert a pause into your test and open the developer tools, you can debug the application like you would during development. You can learn how to do that in [[Using the Moodle App in a browser]].
If you insert a pause into your test and open the developer tools, you can debug the application like you would during development. You can learn how to do that in [[Using the Moodle App in a browser]].


Additionally, you can see log information in the console about which Behat steps have been carried out so far, and whether Behat is waiting for anything. Here is an example:
Additionally, you can see log information in the console about which Behat steps have been carried out so far, and whether Behat is waiting for anything. Here is an example:
<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">
VM649:391 BEHAT: 17:45:15.477 Action - Set field Username to: student2
VM649:391 BEHAT: 17:45:15.477 Action - Set field Username to: student2
Line 292: Line 226:
VM649:391 BEHAT: 17:45:16.653 PENDING-:  
VM649:391 BEHAT: 17:45:16.653 PENDING-:  
</syntaxhighlight>
</syntaxhighlight>
While the test is paused, you can also carry out some of the app Behat steps manually by typing commands into the console, which is convenient if you're not quite sure what command would work. The commands are available in a global object called <code>behat</code>. Here are some examples:
While the test is paused, you can also carry out some of the app Behat steps manually by typing commands into the console, which is convenient if you're not quite sure what command would work. The commands are available in a global object called <code>behat</code>. Here are some examples:
<syntaxhighlight lang="javascript">
<syntaxhighlight lang="javascript">
behat.setField('Password', 'student2');
behat.setField('Password', 'student2');
Line 300: Line 232:
behat.pressStandard('back');
behat.pressStandard('back');
</syntaxhighlight>
</syntaxhighlight>
There are more functions in the object; try using the browser's autocomplete to see the options, or look at the source in [https://github.com/moodlehq/moodle-local_moodlemobileapp/blob/master/tests/behat/app_behat_runtime.js app_behat_runtime.js].
There are more functions in the object; try using the browser's autocomplete to see the options, or look at the source in [https://github.com/moodlehq/moodle-local_moodlemobileapp/blob/master/tests/behat/app_behat_runtime.js app_behat_runtime.js].


If you're using <code>moodle-docker</code>, remember that you can interact with the browser [https://github.com/moodlehq/moodle-docker#using-vnc-to-view-behat-tests using VNC].
If you're using <code>moodle-docker</code>, remember that you can interact with the browser [https://github.com/moodlehq/moodle-docker#using-vnc-to-view-behat-tests using VNC]. With a VNC client you can view in real-time what behat is doing in the browser.
 
=== Writing custom steps ===
=== Writing custom steps ===
If you find something missing to test your code, you can always implement custom steps.
If you find something missing to test your code, you can always implement custom steps.


Line 312: Line 241:


You can learn more about writing custom steps in the [[Writing new acceptance test step definitions]] page, and if you want to see how the steps that are specific to the app work, you should look into [https://github.com/moodlehq/moodle-local_moodlemobileapp/blob/master/tests/behat/behat_app.php behat_app.php] and [https://github.com/moodlehq/moodle-local_moodlemobileapp/blob/master/tests/behat/app_behat_runtime.js app_behat_runtime.js].
You can learn more about writing custom steps in the [[Writing new acceptance test step definitions]] page, and if you want to see how the steps that are specific to the app work, you should look into [https://github.com/moodlehq/moodle-local_moodlemobileapp/blob/master/tests/behat/behat_app.php behat_app.php] and [https://github.com/moodlehq/moodle-local_moodlemobileapp/blob/master/tests/behat/app_behat_runtime.js app_behat_runtime.js].
== Upgrading tests from an older version ==
== Upgrading tests from an older version ==
If you wrote tests before the app started using Ionic 5 (in version 3.9.5), it is possible that your tests are not working any longer. This guide has been rewritten with the latest information, so make sure to read the rest of the document to see what changed.
If you wrote tests before the app started using Ionic 5 (in version 3.9.5), it is possible that your tests are not working any longer. This guide has been rewritten with the latest information, so make sure to read the rest of the document to see what changed.


In general though, upgrading your current tests should be mostly straightforward. Here are some overall things to keep in mind:
In general though, upgrading your current tests should be mostly straightforward. Here are some overall things to keep in mind:
* Ionic 5 starts using [https://developer.mozilla.org/en-US/docs/Web/Web_Components/Using_shadow_DOM the Shadow DOM], and that's the source of many issues for the previous version of the Behat tests. The built-in steps have been rewritten to keep that in mind, and mostly should work the same way. One important difference is that they look for content using accessibility rules, so some of your previous assumptions may not be working.
* Ionic 5 starts using [https://developer.mozilla.org/en-US/docs/Web/Web_Components/Using_shadow_DOM the Shadow DOM], and that's the source of many issues for the previous version of the Behat tests. The built-in steps have been rewritten to keep that in mind, and mostly should work the same way. One important difference is that they look for content using accessibility rules, so some of your previous assumptions may not be working.
* Before this update, it was safe to use the standard <code>I should see</code> step. But given the problems mentioned, it is likely that it breaks down in many situations. Instead, you should use the new <code>I should find ... in the app</code> steps.
* Before this update, it was safe to use the standard <code>I should see</code> step. But given the problems mentioned, it is likely that it breaks down in many situations. Instead, you should use the new <code>I should find ... in the app</code> steps.
Line 328: Line 254:


If you also need to upgrade your plugin, and not just the tests, check out the [[Adapt your Mobile plugins to Ionic 5]] page.
If you also need to upgrade your plugin, and not just the tests, check out the [[Adapt your Mobile plugins to Ionic 5]] page.
== Troubleshooting ==
== Troubleshooting ==
=== General advice ===
=== General advice ===
If you are stuck with an error and you can't find a way to continue, here's a list of things you can do:  
If you are stuck with an error and you can't find a way to continue, here's a list of things you can do:  
 
* Make sure you added <code>$CFG->behat_ionic_wwwroot = "http://localhost:8100";</code> (or equivalent) to your <code>config.php</code> file, and that url is reachable from the host where your Moodle site is running.
* Make sure you added <code>$CFG->behat_ionic_wwwroot = "http://localhost:8100";</code> to your <code>config.php</code> file.
* Remember when you need to re-run <code>admin/tool/behat/cli/init.php</code>, and make sure that you see "Configured app tests for version X.X.X". When in doubt, just run it again; it may fix your problem.
* Mobile Behat tests don't work well with XDebug, so if you're using it, turn it off in <code>php.ini</code> while running the tests. Also, remeber to restart Apache if necessary.
* Remember when you need to re-run <code>admin/tool/behat/cli/init.php</code>, and make sure that you see "Configured app tests for version X.X.X".
* It is possible that your tests break if you're using an unstable version of the app. Try to use stable versions using the <code>master</code> branch if you're working with the source code or tagged releases if you're using Docker.
* It is possible that your tests break if you're using an unstable version of the app. Try to use stable versions using the <code>master</code> branch if you're working with the source code or tagged releases if you're using Docker.
 
* Mobile Behat tests don't work well with XDebug, so if you're using it, turn it off in <code>php.ini</code> while running the tests. Also, remember to restart Apache if necessary.
=== Unable to load app version from http://moodleapp:8100/config.json ===
=== Unable to load app version from http://moodleapp:8100/config.json ===
 
This message appears when the Moodle site is not able to reach the app. Make sure that the url is available from the host you're running the Behat commands from. Also make sure that the app is actually running at the specified url.
This message appears when the Moodle site is not able to reach to app. Make sure that the url is available from the host you're running the Behat commands from. Also make sure that the app is actually running at the specified url.


It's ok if the actual <code>/config.json</code> url doesn't work, that's actually a remnant from legacy code. The url that Moodle is actually looking for is <code>/assets/env.json</code>.
It's ok if the actual <code>/config.json</code> url doesn't work, that's actually a remnant from legacy code. The url that Moodle is actually looking for is <code>/assets/env.json</code>.
=== The plugins required by this course could not be loaded correctly... ===
=== The plugins required by this course could not be loaded correctly... ===
This means either some activity on the course is not adapted to support the moodle app or there is a timeout in the request to your behat site.
This means either some activity on the course is not adapted to support the moodle app or there is a timeout in the request to your behat site.


To clear the timeout message, open the app in your [[Using_the_Moodle_App_in_a_browser|development browser]], open the Inspector, open the Application tab, select Clear storage, press Clear site data, close Inspector, close the tab with mobile site, re-open mobile site in new tab and log in. Then in a separate tab, log in to your behat site (you can find the url in <code>$CFG->behat_wwwroot</code> within your <code>config.php</code> file) and make sure you can get into the course without seeing the error.
To clear the timeout message, open the app in your [[Using_the_Moodle_App_in_a_browser|development browser]], open the Inspector, open the Application tab, select Clear storage, press Clear site data, close Inspector, close the tab with mobile site, re-open mobile site in new tab and log in. Then in a separate tab, log in to your behat site (you can find the url in <code>$CFG->behat_wwwroot</code> within your <code>config.php</code> file) and make sure you can get into the course without seeing the error.
=== Fatal error: Maximum execution time of 30 seconds exceeded in... ===
=== Fatal error: Maximum execution time of 30 seconds exceeded in... ===
This means that your local site has not been updated/visited since an upgrade. Just go to your local behat site (you can find the url in <code>$CFG->behat_wwwroot</code> within your <code>config.php</code> file), log in as admin and run notifications, then visit a course. Do this step often to avoid timeouts!
This means that your local site has not been updated/visited since an upgrade. Just go to your local behat site (you can find the url in <code>$CFG->behat_wwwroot</code> within your <code>config.php</code> file), log in as admin and run notifications, then visit a course. Do this step often to avoid timeouts!
=== Test fails because of the browser language ===
=== Test fails because of the browser language ===
If your operating system is in a different language than English, the tests may fail.
If your operating system is in a different language than English, the tests may fail.


Line 363: Line 277:


To do so, just set the <code>forcedefaultlanguage</code> attribute to <code>"en"</code> in your <code>moodle.config.json</code> file in the app.
To do so, just set the <code>forcedefaultlanguage</code> attribute to <code>"en"</code> in your <code>moodle.config.json</code> file in the app.
=== Application build gets killed without any error information ===
In some situations, it is possible that you see <code>Killed</code> in the console and a command suddenly stops without any further information. In these situations, make sure to check the [[#General_advice|General advice]] section, but it is possible that your computer is running out of memory.


If you are running the scripts inside of a Docker container, make sure that Docker is allocated enough memory. If you are using Docker desktop (for example, on a Mac), you can inspect these settings under Preferences > Resources > Advanced > Memory.
=== [Mac] running moodle-docker commands show grep usage options and do nothing else ===
This is [https://github.com/moodlehq/moodle-docker/issues/188 a known issue] in moodle-docker for Mac. The workaround for now is just to explicitly initialize the <code>MOODLE_DOCKER_APP_RUNTIME</code> variable in your local environment.
[[Category: Quality Assurance]]
[[Category: Quality Assurance]]
[[Category: Behat]]
[[Category: Behat]]
[[Category: Mobile]]
[[Category: Mobile]]
[[Category: Moodle App Ionic 5]]
[[Category: Moodle App Ionic 5]]

Latest revision as of 13:01, 14 July 2022

Important:

This content of this page has been updated and migrated to the new Moodle Developer Resources. The information contained on the page should no longer be seen up-to-date.

Why not view this page on the new site and help us to migrate more content to the new site!


In order to run tests that carry out automated functionality testing for the Moodle App, you can write Acceptance tests. This can be useful if you want to test plugins that are compatible with the app, or you're contributing to the app core. Behat tests for the app work the same way as tests for Moodle core, but they are not run as part of a normal Behat execution and there are some differences that we'll go through in this page.

A key point is that these tests are run using the Moodle Behat infrastructure, and don't depend only on the app codebase. Therefore, you will need a Moodle development setup as described in Setting up development environment.

The main advantages of this approach are:

  • It is easy for third-party plugin authors to create tests for app features in exactly the same way that they create tests for website features.
  • Where institutions run tests automatically, it should be relatively easy to include some app tests within the existing approach.
  • This system does not require any mobile device hardware and should work on all common platforms.


Installation

In order to run tests for the app, you will need to run both a Moodle site and the Moodle App.

The Moodle site should be version 3.9.7+, 3.10.4+ or newer (3.11, 4.0, etc.). You also need to install the local_moodlemobileapp plugin, using the version that corresponds with the version of the Moodle App that you're testing on. If you have tests for an older version, you can read the Upgrading tests from an older version section.

We recommend that you use moodle-docker, because it's configured to run mobile tests and you can skip reading this entire section. You won't even need to clone the app repository.

Nevertheless, if you still have to run the projects in your local machine, you can read the following instructions.

Configuring the Moodle site

You can learn how to run a Moodle site locally in Setting up development environment.

Remember to install the local_moodlemobileapp plugin with the same version that you're using for the mobile app.

Configuring the Moodle App

If you are going to modify the application code, you can learn how to run it locally in Setting up your development environment for the Moodle App. You only need to run the application in a browser, so you can skip the instructions for Android/iOS. Make sure to launch the application on the testing environment, running npm run serve:test.

If you only intend to run the app with the goal of executing Behat tests, you can use the Docker images for the Mobile App. Again, make sure that you're running them on the testing environment using the -test suffix.

However you set up the environment, if you change the version of the app you'll need to re-run the Behat init command so that your Moodle site knows about it.

Configuring Behat

In order to enable app testing, you need to add the following configuration to your site's config.php file: 

$CFG->behat_ionic_wwwroot = 'http://localhost:8100';

The url you use here must be reachable by your Moodle site, and the application needs to be served at this url when running tests and also when you initialise the Behat environment.

The Moodle App only works in Chromium-based browsers, so mobile tests will be ignored if you are using any other browser. You can learn how to configure the browser used in your tests in the Running acceptance test page.

If everything is configured properly, you should see "Configured app tests for version X.X.X" after running admin/tool/behat/cli/init.php.

Running Behat

To run mobile tests in Behat, simply launch Behat in the usual way. The app tests all have the @app tag, so if you want to run all the mobile tests you can use --tags=@app.

It is OK to combine mobile and web tests in the same run.

Writing tests

This page assumes you already know all about Writing acceptance tests in general.

Test structure

Mobile app test scenarios should be marked @app and @javascript in addition to any other tags.

You are writing a normal Behat test and this is likely to require background steps, such as creating courses, users, groups, etc.

Start the app

When you want to get started testing the application, you can use the following step to launch the application: 

Given I enter the app

This will:

  • Set up all the Moodle server settings to allow the Moodle App to connect.
  • Restart the browser, this is needed to ensure that it doesn't use data from previous runs.
  • Set the browser to a suitable phone size (you can change it with other steps if you want a tablet or a different size).
  • Open the app in the test browser.
  • Inject the necessary JavaScript code to support Behat testing.
  • Skip the onboarding and enter the site url in the initial screens of the app, if necessary.


After this step completes, if it is the first time you ran the app inside this scenario, you will be at the login screen. If you logged in earlier, you will be at the start page.

You can also use this step if you are already using the app and it will restart it.

Log in to the app

To log in, you can use the following step: 

When I log in as "student"

This is the same step that's used to log into standard Moodle, and it works in the app as well. You should have created the user in background steps, and it will log in using the text as both username and password.

You will then be left at the start page.

Standard steps

Technically, you can use any standard Behat action in the app. However, most of them will probably not work as you expect because the app runs on a different environment. It is still a website, but it's built using Ionic Framework.

One important problem is that the app has a complex DOM, and previous pages that are "back" from your current page may still be present in the DOM. Which means that any steps that just look for the first matching element in the DOM are likely to look for elements on a page you're not even on.

Another issue is that Ionic relies heavily on the Shadow DOM, and most steps in standard Moodle are not prepared to handle that.

For these and other reasons, there are some steps that have been implemented specifically for the app. You can distinguish them from others because most of them end with "in the app".

Having said that, here's a list of steps that work and you can use reliably.

  • Any step you normally need to set up information in Moodle — For example, creating courses, users, etc.
  • I change viewport size to "{width}x{height}" — You can use this step to simulate switching between portrait and landscape formats.
  • I pause — This step works and it is very useful to debug your scenario.

Actions

When I press "Course 1" in the app

This will click an element found using accessibility rules, so it could be visible text, content inside aria-label, content described by ara-labelledby, etc. It should work for links, buttons and other clickable elements. 

When I press "Course 1" near "Unique text" in the app

You can use this step to narrow matches if the text you're providing is duplicated throughout the page.

The second value, "Unique text" in this example, should be unique on the page. Otherwise, you may have issues finding the element that you seek. The system will press the element matching your text that is nearest to the one found using the unique text.

Nearest is defined in terms of the DOM rather than pixel position; it is based on the number of steps you would have to take up the tree from the candidate element before you get to a shared ancestor with the unique text. 

When I select "Item 1" in the app
When I select "Item 1" near "Unique text" in the app
When I unselect "Item 1" in the app
When I unselect "Item 1" near "Unique text" in the app

You can use these steps to select or unselect radio buttons, check boxes, and such.

You could use the previous I press step as well, but in some cases you will notice that it doesn't work as you expect. This is due to some internal quirks of how Ionic renders these components, so prefer using this specific steps where possible. 

When I set the field "field name" to "text value" in the app
When I set the field "field name" near "Unique text" to "text value" in the app

This sets a text field with the given value. The same rules will apply to find the input element as for clicking, so using the input name will not suffice. This is in order to encourage accessibility best practices. The only difference with the previous step is that this only matches fillable elements such as <input>, <textarea> and elements with contenteditable="true". 

When I press the back button in the app
When I press the more menu button in the app
When I press the page menu button in the app
When I press the user menu button in the app

These steps will press, respectively:

  • The back button — This is the left pointing arrow at top left of the app.
  • The more menu button — This is the icon with at bottom right of the app.
  • The page menu button, if present — This is the icon with the three dots at top right of the app.
  • The user menu button, if present — This is the avatar button at top right of the app present on navigation level 1.


When I switch to the browser tab opened by the app
When I close the browser tab opened by the app

These two steps are necessary if you want to test the transition between the app and a browser.

For example, after pressing "Open in browser" you can use the first step above, and you will be able to use normal Moodle Behat steps to work in the browser tab. Once you're finished, you can use the second step to go back to the app.

Assertions

Like actions, there are some Behat assertions that are specific to the app. 

Then I should find "Course 1" in the app
Then I should find "Course 1" near "Unique text" in the app
Then I should not find "Course 1" in the app
Then I should not find "Course 1" near "Unique text" in the app

These steps can be used to assert that the specified text exists somewhere in the app.

Notice that the standard I should see step may not work in the app because of the Shadow DOM. This step will also search using accessibility rules, so text within aria-label or described with aria-labelledby will work as well. 

Then the header should be "Course 1" in the app

This checks the text of the current page header. It must be an exact match for the specified text.

You could have used the I should find step described previously, but this allows you to specifically check the header as opposed to anything in the page. 

Then "Item 1" should be selected in the app
Then "Item 1" near "Unique text" should be selected in the app
Then "Item 1" should not be selected in the app
Then "Item 1" near "Unique text" should not be selected in the app

You can use these steps to assert whether radio buttons, check boxes, and such are selected or not.

Leaving the app

If you want to leave the app and go back to Moodle within a scenario, simply use a Moodle step that goes to a page. For example, use I am on site homepage or I am on "Course 1" course homepage.

You only need to do this if you want to carry out actions within Moodle after using the app, within the scenario. At the end of your scenario, there is no need to explicitly leave the app; Moodle will automatically start the next scenario on the Moodle start page as usual.

A complete example

This example is a complete feature file that loads the app, opens a course, and asserts that the app is showing the course page: 

@app @javascript
Feature: Test app (demo)
  In order to test something in the app
  As a developer
  I need for this test script to run the app

  Background:
    Given the following "courses" exist:
      | fullname | shortname |
      | Course 1 | C1        |
    And the following "users" exist:
      | username |
      | student  |
    And the following "course enrolments" exist:
      | user     | course | role    |
      | student  | C1     | student |

  Scenario: Try going into the course
    When I enter the app
    And I log in as "student"
    And I press "Course 1" near "Course overview" in the app
    Then the header should be "Course 1" in the app

You can find more complex examples looking at the tests for the app core.

Limitations

Using this approach, there are some limitations you should be aware of:

  • Lack of native functionality — Fundamentally, it is not possible to test behaviour specific to native devices because tests are run in a browser.
  • Missing functionality — There are some known limitations and unsupported features, for example there is currently no obvious way to attach files. Some of these are possible, but they haven't been implemented yet. If something is missing for your use-case, you can submit feature requests in the tracker using the Behat component.

Advanced

Versioning

Behat tests can relate to particular versions of the mobile app. For these situations, there are two types of tags you can add to your scenario or feature:

  • @app_from{version} — These will be included in every app matching the specified version and newer.
  • @app_upto{version} — These will be included in every app matching the specified version and older.


You can use two-digit or three-digit version numbers. For example, you could use @app_from4.0 or @app_upto3.9.5.

After changing the app version used for testing, make sure you re-run Behat init. It is the initialisation process that stores which version of the app you're using.

Testing against multiple app versions

If you need to run tests against multiple versions of the app, you can do it in two ways:

  1. Update the code in the app workspace by checking out a different version.
  2. Maintain multiple copies of the mobile app workspace and switch between them by changing config.php.


In both cases, you'll need to re-run the Behat init command and run the tests again.

Unfortunately, the only way to run this in parallel is to have separate Moodle installations with their own configurations.

Debugging tests

If you insert a pause into your test and open the developer tools, you can debug the application like you would during development. You can learn how to do that in Using the Moodle App in a browser.

Additionally, you can see log information in the console about which Behat steps have been carried out so far, and whether Behat is waiting for anything. Here is an example: 

VM649:391 BEHAT: 17:45:15.477 Action - Set field Username to: student2
VM649:391 BEHAT: 17:45:15.480 PENDING+: DELAY,dom-mutation
VM649:391 BEHAT: 17:45:15.982 PENDING-: DELAY
VM649:391 BEHAT: 17:45:16.28 PENDING-: 
VM649:391 BEHAT: 17:45:16.98 Action - Set field Password to: student2
VM649:391 BEHAT: 17:45:16.106 PENDING+: DELAY,dom-mutation
VM649:391 BEHAT: 17:45:16.607 PENDING-: DELAY
VM649:391 BEHAT: 17:45:16.653 PENDING-:

While the test is paused, you can also carry out some of the app Behat steps manually by typing commands into the console, which is convenient if you're not quite sure what command would work. The commands are available in a global object called behat. Here are some examples: 

behat.setField('Password', 'student2');
behat.press('Log in', 'Forgotten');
behat.pressStandard('back');

There are more functions in the object; try using the browser's autocomplete to see the options, or look at the source in app_behat_runtime.js.

If you're using moodle-docker, remember that you can interact with the browser using VNC. With a VNC client you can view in real-time what behat is doing in the browser.

Writing custom steps

If you find something missing to test your code, you can always implement custom steps.

If you're writing a plugin, you can include a new class under tests/behat/behat_{youpluginname}.php. If you're working on application code, you can always update behat_app.php as well.

You can learn more about writing custom steps in the Writing new acceptance test step definitions page, and if you want to see how the steps that are specific to the app work, you should look into behat_app.php and app_behat_runtime.js.

Upgrading tests from an older version

If you wrote tests before the app started using Ionic 5 (in version 3.9.5), it is possible that your tests are not working any longer. This guide has been rewritten with the latest information, so make sure to read the rest of the document to see what changed.

In general though, upgrading your current tests should be mostly straightforward. Here are some overall things to keep in mind:

  • Ionic 5 starts using the Shadow DOM, and that's the source of many issues for the previous version of the Behat tests. The built-in steps have been rewritten to keep that in mind, and mostly should work the same way. One important difference is that they look for content using accessibility rules, so some of your previous assumptions may not be working.
  • Before this update, it was safe to use the standard I should see step. But given the problems mentioned, it is likely that it breaks down in many situations. Instead, you should use the new I should find ... in the app steps.
  • Similar to the last point, some radio inputs and checkboxes that worked before are broken. You should be able to use the new I select ... in the app steps instead.
  • If you were relying in xpath or css selectors before, they will probably not work anymore. Even if you try to patch them, these selectors don't pierce through the Shadow DOM. In any case, it's always better to use accessible locators in your test like a real user would, so you can use this opportunity to improve accessibility in your plugin.
  • Pay special attention to any assertions such as should not exist that you have in your tests. These assertions will not fail, because the elements won't be found. But if you get an eventual bug when something is shown that shouldn't, those steps will probably not pick it up because the locators may have changed.
  • If you were running your tests in CI, there is a new dependency even if you're only testing a plugin and not running the application tests. The test definitions have been moved from core to the local_moodlemobileapp plugin, and you should have it installed in your Moodle site running the tests. This was done in order to decouple application code from the core.


If you also need to upgrade your plugin, and not just the tests, check out the Adapt your Mobile plugins to Ionic 5 page.

Troubleshooting

General advice

If you are stuck with an error and you can't find a way to continue, here's a list of things you can do:

  • Make sure you added $CFG->behat_ionic_wwwroot = "http://localhost:8100"; (or equivalent) to your config.php file, and that url is reachable from the host where your Moodle site is running.
  • Remember when you need to re-run admin/tool/behat/cli/init.php, and make sure that you see "Configured app tests for version X.X.X". When in doubt, just run it again; it may fix your problem.
  • It is possible that your tests break if you're using an unstable version of the app. Try to use stable versions using the master branch if you're working with the source code or tagged releases if you're using Docker.
  • Mobile Behat tests don't work well with XDebug, so if you're using it, turn it off in php.ini while running the tests. Also, remember to restart Apache if necessary.

Unable to load app version from http://moodleapp:8100/config.json

This message appears when the Moodle site is not able to reach the app. Make sure that the url is available from the host you're running the Behat commands from. Also make sure that the app is actually running at the specified url.

It's ok if the actual /config.json url doesn't work, that's actually a remnant from legacy code. The url that Moodle is actually looking for is /assets/env.json.

The plugins required by this course could not be loaded correctly...

This means either some activity on the course is not adapted to support the moodle app or there is a timeout in the request to your behat site.

To clear the timeout message, open the app in your development browser, open the Inspector, open the Application tab, select Clear storage, press Clear site data, close Inspector, close the tab with mobile site, re-open mobile site in new tab and log in. Then in a separate tab, log in to your behat site (you can find the url in $CFG->behat_wwwroot within your config.php file) and make sure you can get into the course without seeing the error.

Fatal error: Maximum execution time of 30 seconds exceeded in...

This means that your local site has not been updated/visited since an upgrade. Just go to your local behat site (you can find the url in $CFG->behat_wwwroot within your config.php file), log in as admin and run notifications, then visit a course. Do this step often to avoid timeouts!

Test fails because of the browser language

If your operating system is in a different language than English, the tests may fail.

Chrome does not have an easy way to force the browser language to English, so the best way to solve the issue is forcing the app default language to English.

To do so, just set the forcedefaultlanguage attribute to "en" in your moodle.config.json file in the app.

Application build gets killed without any error information

In some situations, it is possible that you see Killed in the console and a command suddenly stops without any further information. In these situations, make sure to check the General advice section, but it is possible that your computer is running out of memory.

If you are running the scripts inside of a Docker container, make sure that Docker is allocated enough memory. If you are using Docker desktop (for example, on a Mac), you can inspect these settings under Preferences > Resources > Advanced > Memory.

[Mac] running moodle-docker commands show grep usage options and do nothing else

This is a known issue in moodle-docker for Mac. The workaround for now is just to explicitly initialize the MOODLE_DOCKER_APP_RUNTIME variable in your local environment.

Retrieved from "https://docs.moodle.org/dev/index.php?title=Acceptance_testing_for_the_Moodle_App&oldid=63530"
Powered by MediaWiki