Project Challenges: Files

A project challenge is built out of one or more virtual files. The file structure is mostly open-ended, with some restrictions to accommodate our code runner.

File Commands

Each file will have various commands associated with it, such as rename, delete, or configuring access levels. Most file commands are in 3 ways:

• If the file is open, they will be available directly in the file editor's toolbar
• Use the file menu button inside the file tree. When hovering over a file, it will either be a menu icon () or the access icon if the access has been changed. (See below)
• Right-click on the file name in the file tree, which will bring up the file menu.

Basic File Editing

Opening Files

Click on a file in the file tree to open its editor.

Creating Files & Directories

There are several ways you can create or add files to our IDE:

• In either the Project Files or Reference Solution Files tree, use the plus icon () to create a new file or directory.
• Use the Duplicate () action from the file commands.
• Drag-and-drop files from your system directly into the IDE. You can drag in single files, groups of files, or even complete file trees.

Moving and Renaming Files

You can move or rename a file using the Rename () action from the file commands.

To move a file to a different folder, simply change its path in the rename dialog.

Deleting Files

You can delete a file using the Delete () action from the file commands.

A deleted file is moved to Deleted Files. You can undelete the file from this location if it was a mistake.

File Configuration

There are several options available to customize how files work for the candidate. Use these customizations to help provide an optimal testing experience for your candidate.

Access Level

The access level affects the editability and visibility of a file for the candidate. By changing this value, you can create files that are read-only, unreadable, or even completely hidden. These changes can be both for reducing complexity (by removing the amount of variable content for the candidate), and improving submission test quality (by hiding content we don't want the candidate to see).

Read/Write

This is the default, and highest level of access. A Read/Write file is fully editable by a candidate—including being able to delete or move the file. Unless explicitly excluded, these files will be included on both candidate and submission tests, and are the primary source for solving challenges.

Deletable

This option is only available for read/write files. If unchecked, the file cannot be deleted or renamed. The candidate can still edit this file.

This can be useful when you want the candidate to focus on correcting or improving a file, but not to worry about file names or breaking tests.

Read Only

A Read-Only file is fully visible to the candidate, but they cannot change its contents. These have many uses:

• Documentation or other content only provided for visibility.
• Tests that you would like to show the candidate, but do not want them to be able to edit. These could be base tests that you want to make sure the candidate doesn't accidentally overwrite, or even tests that are part of the submission tests.
• Library code you don't want the candidate to modify, which might represent 3rd party libraries or existing application code that shouldn't be modified.

Restricted

If a file is part of the test, but you don't want the candidate to view its contents, Restricted provides the ability to have a file or directory that's visible within the IDE, but its contents are completely hidden. Directories will not be able to be expanded, and files will not be openable.

Use cases here include:

• Hidden tests that we want to identify as existing, but not let the candidate view. This would be similar to how classic code challenges handle submission tests.
• Creating virtual 3rd-party services such as "remote" APIs where the inner workings are not visible to the candidate.
• Hiding content that otherwise may give away the solution, but we want the candidate to be aware the file exists (so they don't try to overwrite it).

Hidden

A fully Hidden file or directory never shows up in the UI for the candidate. If they accidentally try to create a file that overlaps with a hidden file or directory, they'll get an error message about it being a restricted path, without any more information.

It's not often recommended to have fully hidden files or directories, as this can lead to a not entirely realistic testing environment. However, there are a few cases where fully hiding a directory or file make sense:

• If we have a large internal dependency and it would just be noise, and unlikely the candidate would write to that directory.
• If we want to hide a lot of submission tests from the UI. In this case, it's recommended to place all the submission tests inside a sub directory, and hide that directory.

Run/Submit Options

A few other options are available to files for improving the testing experience and assessment results.

Include on candidate tests & Include on submission

These options define when to send a file to the code runner. (Empty directories are never sent to the code runner.)

Both options are enabled by default, which means the file will always be included when running code.

• If a file is not part of the code solution, such as documentation, you can uncheck both options to not bother sending it.
• Uncheck Include on candidate tests if you don't want the file to be included when a candidate is running their tests. This could be because it's a set of tests for submission only.
• Uncheck Include on submission if you don't want the file to be included when submitting the solution. This may be because it's candidate-editable tests, and we don't want their tests to affect the final score. See also Submission Ignore Paths for more ways on limiting how a candidate can affect the results.

Go to/Create Reference/Project File

Use this action () to quickly create or toggle between reference and project files. Depending on your workflow, it may be faster to build the reference solution file first, then once all the tests are passing, create the project file and remove the working code. Or you may prefer to work in the opposite manner.

Submission Ignore Paths

Under Run Configuration is an option to add one or more Submission Ignore Paths. These paths are regular expressions that override any Access Level by allowing you to ignore edits & new files made by candidates during their submission.

Using submission ignore paths allows the candidate to create files that can help them test their code—such as additional unit tests or specs—without affecting the submission scoring process.

The way they work is any candidate-created file that matches an ignore path is not included in the runtime files. If a Project File matches an ignore path, the original, unedited Project File will be used instead of the candidate modified one.

Downloading Project Files

Under Challenge Configuration → Description & Categorization → Advanced Options, you can enable the ability for candidates to download a zip of all files within a challenge while taking an assessment.