Search moodle.org's
Developer Documentation
Developer Documentation
- Bug fixes for general core bugs in 4.2.x will end 22 April 2024 (12 months).
- Bug fixes for security issues in 4.2.x will end 7 October 2024 (18 months).
- PHP version: minimum PHP 8.0.0 Note: minimum PHP version has increased since Moodle 4.1. PHP 8.1.x is supported too.
/lib/xapi/tests/external/ -> post_statement_test.php (source)
Differences Between: [Versions 310 and 402] [Versions 311 and 402] [Versions 39 and 402] [Versions 400 and 402] [Versions 401 and 402]
This file contains unit test related to xAPI library.
| Copyright: | 2020 Ferran Recio |
| License: | http://www.gnu.org/copyleft/gpl.html GNU GPL v3 or later |
| File Size: | 490 lines (17 kb) |
| Included or required: | 0 times |
| Referenced: | 0 times |
| Includes or requires: | 0 files |
Defines 2 classes
post_statement_test:: (3 methods):
setupBeforeClass()
setUp()
get_extenal_class()
extends:: (13 methods):
validate_component()
post_statements_data()
get_valid_statement()
test_component_names()
components_provider()
test_invalid_json()
invalid_json_provider()
test_statements_agent()
test_statements_group()
statement_provider()
test_group_disabled()
group_statement_provider()
test_full_batch_rejected()
Class: post_statement_test - X-Ref
Unit tests for xAPI statement processing webservice.| setupBeforeClass() X-Ref |
| Setup to ensure that fixtures are loaded. |
| setUp() X-Ref |
| Setup test. |
| get_extenal_class() X-Ref |
| Return a xAPI external webservice class to operate. The test needs to fake a component in order to test without using a real one. This way if in the future any component implement it's xAPI handler this test will continue working. return: post_statement the external class |
| validate_component(string $component) X-Ref |
| No description |
| post_statements_data(string $component, $data, array $expected) X-Ref |
| This function do all checks from a standard post_statements request. The reason for this function is because statements crafting (special in error scenarios) is complicated to do via data providers because every test need a specific testing conditions. For this reason alls tests creates a scenario and then uses this function to check the results. param: string $component component name param: mixed $data data to encode and send to post_statement param: array $expected expected results (i empty an exception is expected) |
| get_valid_statement(array $items = []) X-Ref |
| Return a valid statement object with the params passed. All tests are based on craft different types os statements. This function is made to provent redundant code on the test. param: array $items array of overriden statement items (default []) return: statement the resulting statement |
| test_component_names(string $component, array $expected) X-Ref |
| Testing different component names on valid statements. param: string $component component name param: array $expected expected results |
| components_provider() X-Ref |
| Data provider for the test_component_names tests. return: array |
| test_invalid_json(string $json) X-Ref |
| Testing raw JSON encoding. This test is used for wrong json format and empty structures. param: string $json json string to send |
| invalid_json_provider() X-Ref |
| Data provider for the test_components tests. return: array |
| test_statements_agent(bool $multiple, bool $validactor, bool $validverb, array $expected) X-Ref |
| Testing agent (user) statements. This function test several scenarios using different combinations of statement rejection motives. Some motives produces a full batch rejection (exception) and other can leed to indivual rejection on each statement. For example,try to post a statement without $USER in it produces a full batch rejection, while using an invalid verb on one statement just reject that specific statement That is the expected behaviour. param: bool $multiple if send multiple statements (adds one valid statement) param: bool $validactor if the actor used is valid param: bool $validverb if the verb used is valid param: array $expected expected results |
| test_statements_group(bool $multiple, bool $validactor, bool $validverb, array $expected) X-Ref |
| Testing group statements. This function test several scenarios using different combinations of statement rejection motives. Some motives produces a full batch rejection (exception) and other can leed to indivual rejection on each statement. For example,try to post a statement without $USER in it produces a full batch rejection, while using an invalid verb on one statement just reject that specific statement That is the expected behaviour. param: bool $multiple if send multiple statements (adds one valid statement) param: bool $validactor if the actor used is valid param: bool $validverb if the verb used is valid param: array $expected expected results |
| statement_provider() X-Ref |
| Data provider for the test_components tests. return: array |
| test_group_disabled(bool $usegroup1, bool $usegroup2, array $expected) X-Ref |
| Test posting group statements to a handler without group actor support. Try to use group statement in components that not support this feature causes a full statements batch rejection. param: bool $usegroup1 if the 1st statement must be groupal param: bool $usegroup2 if the 2nd statement must be groupal param: array $expected expected results |
| group_statement_provider() X-Ref |
| Data provider for the test_components tests. return: array |
| test_full_batch_rejected() X-Ref |
| Test posting a statements batch not accepted by handler. If all statements from a batch are rejectes by the plugin the full batch is considered rejected and an exception is returned. |
