This page is a reference for writing Code Submission Tests (CSTs) for Epi-Workbench coding exercises. Epi-Workbench CSTs rely heavily on the testthat package; However, this page is not intended to comprehensively document the testthat package. For full documentation, see testthat documentation.

Page Contents

• Header 1
  • Header 2
  • Header 2
  • Header 2
  • Header 2
• Header 1
  • Header 2
  • Header 2
  • Header 2

Using EWBTemplates Addins

There are multiple ways to create coding exercises.

The EWBTemplates package offers to helper functions to make the process easier. However, there are multiple options even when using the EWBTemplates package.

No modification code blocks

Here is the easiest way to get started in the most basic scenario (a no modification code block):

• Install and load EWBTemplates.
• Click Addins -> Insert Coding Exercise -> No Modification (CSTs for unmodified code blocks)

This will add:

• Coding exercise block: Empty
• Solution code block: Empty
• Hidden code block: Containing the basic code testing scaffolding
• Test code block: Containing a CST to check that the code in the coding exercise block wasn't modified
• Hint block: Appropriate for a no modification coding exercise

Writing CST Descriptions

If a CST fails, a toast box will appear in the top-right corner of the screen. The first thing the learner will see in the toast is TEST FAILED: followed by a description of the test that failed. The description is taken from the desc argument to the test_that() function used to write the CST.

For example, if we wrote the following CST:

test_that("Submit code without modification", {
  if (trimws(learner_code) != "1 + 1") {
    fail("This code block already contains the correct code. Please submit it without making any changes. 
If you accidentally modified the code, click the reset button (🔁) on the toolbar to restore the original version. 
Want to experiment or try something different? Open the interactive code console (</>) to explore safely without affecting your submission.")
  } else {
    succeed()
  }
})

The toast description would say:

TEST FAILED:
Submit code without modification

From chapter 13 of R Packages (2e):

It’s common to write the description (desc) to create something that reads naturally, e.g. test_that("basic duplication works", { ... }). A test failure report includes this description, which is why you want a concise statement of the test’s purpose, e.g. a specific behaviour.

Summary:

• The test_that() description should be a concise statement of the CST's purpose.
• It should not give aways the answer.
• It should be followed by a failure message that provides learners with more information about why the CST failed and how to fix it. See Writing-CST-Feedback