Abschnittsübersicht

◄Tests ausführen
►Eigene Schritte schreiben

  • Behat-Tests liegen immer im Verzeichnes /tests/behat/ des Plugins. Unterschiedliche Tests sollten in eigenen Dateien mit der Endung *.feature liegen.

    • Aufbau einer feature-Datei

      Die @-Tags am Anfang können dazu verwendet werden, um beim tatsächlichen Testen nur eine spezielle Auswahl der Testfälle zu berücksichtigen. Der entsprechende Tag wird dafür in Zeile 20 der run.sh-Datei eingesetzt (siehe oben).

      Einzelnen Test-Szenarien können zusätzlich mit einem Javascript-Tag annotiert werden, falls enthaltene Schritte Javascript zur Ausführung benötigen. Generell sind Javascript-Tests jedoch wesentlich langsamer als reguläre Tests. Sollten alle Szenarien Javascript benötigen, reicht es aus, den Tag am Anfang der Datei zusammen mit den anderen Tags zu setzen.

      Tests sollten im Allgemeinen folgenden Aufbau haben: 
       
      1. Given: Diese Schritte werden dazu verwendet, die Test-Situation bereitzustellen. Üblicherweise werden hier Benutzer, Kurse oder Plugin-Instanzen erstellt. Der Given-Teil soll noch nichts testen, deswegen sollte er kurz und verlässlich sein.
      2. When: Hier werden die Aktionen beschrieben, die die Test-Umgebung zu dem Punkt führen, an dem tatsächlich Bedingungen geprüft werden sollen. Dies kann bspw. das Einloggen, Navigieren zwischen Seiten, das Einreichen oder das Bewerten von Aufgaben beinhalten.
      3. Then: In diesen Schritten soll überprüft werden, ob sich das Plugin tatsächlich so verhält wie erwartet. Hier geschehen in der Regel recht simple Abfragen, z. B. ob ein Text oder ein bestimmtes Element sichtbar bzw. nicht sichtbar ist.
       
      Ein konkreter Testfall sollte jedes dieser drei Worte nur einmal und in genau dieser Reihenfolge enthalten. Falls Given, When oder Then mehrere Schritte enthalten, können dafür die Wörter And und But verwendet werden.
      
Given the following user exists:
  | username   | ccolon             |
  | First name | Colin              |
  | Last name  | Colon              |
  | email      | ccolon@example.com |
And the following course exists:
  | Name      | Jump Judging (Level 1) |
  | Shortname | sjea1                  |
When I log in as "ccolon"
And I navigate to "Site home > Jump Judging (Level 1)"
Then I should see "You are not enrolled in this course"
But I should see "Enrol now"

      Sollten mehreren Szenarien dasselbe Set-Up benötigen, können die entsprechenden Given-Schritte als Background zusammengefasst werden.

      
Background:
    Given the following "courses" exist:
      | fullname | shortname | category | groupmode |
      | Course 1 | C1        | 0        | 1         |
    And the following "users" exist:
      | username | firstname | lastname | email |
      | teacher1 | Theo | Teacher | teacher1@example.com |

      Diese Schritte werden dann vor jedem folgenden Szenario ausgeführt. In den einzelnen Szenarien können noch weitere, individuelle Given-Schritte definiert werden.

    • Beispiel für feature-Datei

      moodle/blocks/tests/behat/restrict_available_blocks.feature
      
@core @core_block
Feature: Allowed blocks controls
  In order to prevent the use of some blocks
  As an admin
  I need to restrict some blocks to be used in courses
 
  Background:
    Given the following "users" exist:
      | username | firstname | lastname | email |
      | teacher1 | Teacher | 1 | teacher1@example.com |
    And the following "courses" exist:
      | fullname | shortname | category |
      | Course 1 | C1 | 0 |
    And the following "course enrolments" exist:
      | user | course | role |
      | teacher1 | C1 | editingteacher |
 
  Scenario: Blocks can be added with the default permissions
    Given I log in as "teacher1"
    And I am on "Course 1" course homepage with editing mode on
    When I add the "Course completion status" block
    And I add the "Activities" block
    Then I should see "Activities" in the "Activities" "block"
    And I should see "Course completion status" in the "Course completion status" "block"
 
  Scenario: Blocks can not be added when the admin restricts the permissions
    Given I log in as "admin"
    And I set the following system permissions of "Teacher" role:
      | block/activity_modules:addinstance | Prohibit |
    And I am on the "Course 1" "permissions" page
    And I override the system permissions of "Teacher" role with:
      | block/completionstatus:addinstance | Prohibit |
    And I log out
    When I log in as "teacher1"
    And I am on "Course 1" course homepage with editing mode on
    Then the add block selector should not contain "Activities" block
    And the add block selector should not contain "Course completion status" block
    • Liste aller zur Verfügung stehender Schritte

      Wenn die in der run.sh-Datei enthaltenen Schritte bis inklusive Zeile 17 (Initialize behat environment) nacheinander im Terminal ausgeführt werden, kann die Test-Instanz anschließend auch im Browser unter localhost:8000 aufgerufen werden. Unter "Site administration > Development > Acceptance Testing" findet sich dort eine vollständige Liste aller Test-Schritte, die für die Moodle-Instanz zu Verfügung stehen, inklusive der Schritte installierter Plugins. Die Funktionsnamen und Beschreibungen werden dabei aus den PHPDoc-Kommentaren der jeweiligen Funktionen generiert.

◄Tests ausführen
►Eigene Schritte schreiben