wiki:DesignAndImplementation/TestHarness

Test Harness Specs

Overview

The test harness will be a web site providing the following functionality:

  • Researchers create game conditions defined as sequences of "levels".
  • Instructors create student accounts and assign them to conditions.
  • Students play fluency games.

Timeline

See milestone:TestHarness.

Student Interaction

  1. Login screen with input fields:
    • Login ID (as defined by instructor).
    • Password or DOB? Alternative forms of authentication?
  2. Selection of game level.
  3. Play games.
    • Each level is a sequence of randomly selected question sets.
    • A level lasts 20 minutes or until the student receives a medal, whichever happens first. However, this is not enforced; the instructor should monitor students so that they are doing the right level.

Instructor Interaction

  1. Login screen with input fields:
    • Instructor ID
    • Password
  2. Table for displaying and editing student accounts. For example:
Roster ID Last Name First Name Login ID Password (or DOB?) Condition
12345 Doe John jdoe foobar TreatmentA
98765 Bloggs Fred fbloggs baz123 Control(2/3)

For version 1, the table is not editable. We can edit MySQL records directly in special circumstances if anything needs to be changed.

There should also be a button for adding a new student.

Researcher Interaction

The researcher defines the conditions, which consists of a series of game levels. Game levels in turn consist of a set of question sets, which are selected randomly (with replacement for version one).

Game levels are defined by the  games.json file.

Implementation

 Source code

The server will be an extension of the node.js GameController example server (http://fluencychallenge.com/fluencydemo). Data persistence with MySQL via the sequelize ORM library.

Database Schema

  • instructor
    • loginID
    • password (hashed)
  • student
    • loginID
    • rosterID (for correlating with external measures).
    • firstName
    • lastName
    • password (cleartext, let teacher see and change this). Or DOB, or another authentication method?
    • conditionID (corresponds to conditions defined in the game config file)
    • instructorID (foreign key to instructor table)
  • question_set_outcome
    • startTime
    • endTime
    • studentID (foreign key to student table)
    • questionSetID (corresponds to game config file)
    • dataFileUUID (UUID corresponding to XML file stored on disk)
    • score
    • medal

Open Questions

  • Are conditions defined per student, or per class/instructor?
    • Defined in the data model per student, but when we upload a class roster, every student in a class should be assigned to a particular condition.

For Version 2

(At an unspecified time in the future.)

  • Progress reporting for instructors.
  • Track student progress and position in game, and follow either sequential or remedial sequence of levels.
  • Enforce the "play until you get a medal or 20 minutes" rule.