Layout Ideas

General Principles

• All text can contain HTML
• Some tests should not show up unless failed
• When current edited file switches, this view should react instantly:
  • if this is a java step in the assignment with a test suite: run normally.
  • if this is a java step in the assignment w/o a test suite: report title of assignment, grey our rest of view w/ message "No tests are associated with this step".
  • if it is some random java file, treat as above (no associated tests...)
  • if this is a non java step in the assignment, grey out completely with message "This is a non-java step".
• If the java file doesn't compile, show the title of the step, grey out whole thing with message "doesn't compile" (maybe a more helpful message?).

---

Contents of the View

• Title of Step (name of assignment in parens?)
• Overall correctness
  • cute visual indication
  • overall message of success
  • number of tests that failed/correct w/ no success
• list of method tests.
  • these are special tests -- more 'limited' than standard junit tests in that they are always about a specific method with specific parameters. E.g., 'reverse("dog")'. These are the kind of tests that codingbat.com runs. Because this is non-standard junit, we should find a way to make these fit into the standard junit syntax. However, the display that our view uses may be different for these, to emphasize that they are testing a method specifically, perhaps.
  • method tests contain:
    • function name, inputs
    • visual indication of correctness
    • expected return value, observed return value (whether correct or incorrect)
    • message when incorrect (?)
• list of full tests
  • these are standard junit tests -- could test anything and everything
  • each full test contains:
    • name
    • description(opt) (this isn't part of a standard junit test)
    • visual indication of correctness
    • message when incorrect
    • message of correctness(?) (this isn't part of a standard junit test)
• list of test bundles
  • We want to be able to hide the details of a test, but show the results. Pedagogically, we don't want students to purely 'code to the test', so we want additional tests which show only correctness.
  • A test bundle contains:
    • name

    • of tests in bundle

    • description
    • visual indication of correctness (% of correct?)
    • message when incorrect

Workflow for updating view

• there will be at least three levels of updating:
  • (1) initial setup: build the view parts, etc
  • (2) test-suite: stick in the name of the test suite, determine what the tests are, populate the names, descriptions for each test into the view.
  • (3) test correctness: determine whether test suite compiles, determine whether each test is successful or not, and show the overall-correctness for the test suite.

Each upper level calls the lower levels. Level 1 only called when first opened. Level 2 initiated when a new test-suite is selected (student moves to a new step in the assignment, for instance). Level 3 initiated continuously, when editor is dirty.