How to add and use Advanced zyLabs in your zyBook

NOTE: To add Advanced zyLabs your zyBook must have zyLabs enabled.  If you'd like to enable (or are unsure if zyLabs are already enabled), contact your Account Executive.

Jump to:

IDE Menu

    Files

    Workspace Settings

    History

Test Bench

Model Solution

Use Visual Studio in the Advanced zyLab

Getting Started

Advanced zyLabs can be added to any existing or new section and provide a workspace for learners to edit and save code live, start servers to view web projects, open GUI applications, select from multiple language options, and more. Start by expanding the chapter containing the section to add an Advanced zyLabs IDE. Expanding a chapter can be done in the table of contents on the zyBook homepage or in the content's sidebar.

Next, click "Add a zyLab" or "Create section" at the bottom of the chapter to create a new section to add a zyLab to. Alternatively, you can click on an existing custom section and add a zyLab there.

From the Add a zyLab menu, either click "Create" to create a new section and advanced zyLab, or click "Copy" to create a new section and import an Advanced zyLab from this or another course.


When inside a custom section, click "Advanced zyLab" or "Import" to add or import one to the page.

When adding an Advanced zyLab, select the language to use next.

This may include the version of the language selected, as well as the option to use our CR2 IDE, the Visual Studio Code editor, or Jupyter options for Python. Learn more about the VSC IDE by clicking here.

Hit "Create" to begin editing the template.

The Template for each Advanced zyLab is what learners will see when the page is published. It can be edited at any time, even after publishing. However, learners will need to "Reset lab to template" to see any changes if they opened the assignment before the template was edited.

IDE Menu

At the top left of the IDE is the Files menu.

Files

Click the icon to open the file tree, where files and folders can be created, re-arranged, uploaded, downloaded, renamed, duplicated, marked as read-only, and deleted.

Files can also be dragged and dropped into the file pane to upload.

The three-dot menu at the end of each file contains some of these options, including language specific options.

Workspace Settings

The settings menu, which can be opened from the cog in the bottom left, provides options to change the default file, write a custom run config, and change the IDE language. Learn more about workspace settings here.

In other IDEs, like VSC, the Workspace Settings are in the top left. Additionally, there will be an option to switch to the Coding Rooms IDE.


Other Settings

The restart virtual environment option will reset the IDE. This option is useful if the IDE becomes unresponsive.

The restore lab data folder resets the data of the workspace back to the template. This will reset database data, like MySQL databases, it will also reset vsc settings, and other lab settings. It will not reset the code or files in the Files tree.

Reset lab to template resets the files in the workspace to match the current template, along with any changes made to workspace settings and "Options".

History

Clicking History opens a playback timeline for everything done in the workspace.

From the Student Activity card, work can be checked keystroke-by-keystroke. Open a student's history and click the forward and back arrows, or click anywhere in the timeline. Alternatively, click the play button to move through the code in that file naturally. If the workspace contains multiple files, the history for the active file will stop when the edits to that file stopped, and the timeline will continue in the next edited file. Click other files in the Files pane to switch between them and continue monitoring edits. 

When moving through the timeline, clicking Restore File will open a prompt to revert the code to the timestamp and state visible in the codepad for the file visible in the timeline.

The event history in the bottom left of the History indicates changes made to the IDE or Files, like the restoration of main.py to a previous state in the event history above.

Click the Legend in the bottom left to disable any of the options for the timeline.

Insertions and deletions indicate notable changes to the code, which could be from a paste, a file restore/reset to template, or uploading a file. File restores bring a file back to a previous state. Reset to template restores the code to the current template's state.

Hover over insertions or deletions to see the amount of characters in that action.

Click the Exit History button to return to the code editor.

Run

Run will compile and run based on the default file, which can be changed from the workspace settings. Workspace settings also allows toggling on a drop-down menu for multiple files.

Run tests, only visible on the edit side, will run all tests in the test bench against the template or model solution, whichever is currently open

Desktop View

After running code in most languages, the Desktop tab will be active. Switch to the Desktop tab to open the virtual desktop view. Some languages open this view by default after clicking run.

The two icons along the right side will open the desktop view in a new tab, or a fullscreen view. Alternatively, enlarge the desktop view by adjusting the top edge of the frame.

Other Icons

A number of other icons are visible across the IDE and noted in the image below.

1. Tutorial, visible only on the submission side

    a. A tutorial button can be clicked at any time to see a walkthrough of the IDE

2. Sync All

    a. Confirms the most recent changes have been synced, and can be clicked to force a sync

3. Console

    a. Use the console to see output, enter input, and enter other commands
    b. Click the + to add another console tab where you can send commands for things like file management, process management, and environment variable management, especially when the first tab is busy

4. Expand Handle

    a. Click and drag to expand or collapse the size of the IDE

Any workspace with web functionality will display output, like HTML, in a webview tab.

Some desktop tabs will change depending on the language, like MySQL, which displays MySQL Workbench.

If the IDE is disconnected from the internet, the connection indicator replaces the sync button to indicate that your work is not being synced.

Hotkeys

There are a number of Hotkeys and shortcuts that can be used inside the IDE.

F1 - Open Command Palette

Right-Click Menu includes useful hotkeys like these:
Alt + Windows + N - Run

Ctrl + F2 - Change All Occurrences

Shift+ Alt+ F - Format Document (Auto-indent)

Ctrl + K - Add instructor comment to highlighted text

Ctrl + F - Find

Ctrl + G - Go to line

Ctrl + , - Make Font Smaller

Ctrl + . - Make Font Larger

Ctrl + / - Toggle programming language comment

Ctrl + Shift + Enter - Insert Line Above

Ctrl + Enter - Insert Line Below

Ctrl + Shift + K - Delete Line

Ctrl + Shift + [ - Fold

Alt + F8 - Go to Next Problem (Error, Warning, Info)

Test Bench

The Test Bench is where autograded tests can be assigned. Just click "Add Test Case" to begin.

Next enter a title and point value for this test.

Then, select a test type, or leave at the default output test.

Choosing the type of test to use depends on how the code should be evaluated. Input/Output can be best for code that produces uniform results, and when the functionality of the code is the most important factor. Unit tests are more complex, but allow for a more rigorous check of the methodology of the code. Bash tests can be easier to write than unit tests, and look primarily at the functionality of the code.

When selecting a unit test, the test bench will default to the most applicable test for the selected language. That test type can be changed by clicking in the Unit Testing Framework dropdown, and selecting another test type, like JUnit 4 for Java workspaces.

A prompt will ask if the current test should be deleted and replaced with the boilerplate for the newly selected framework. Boilerplates establish a guideline for how the selected framework functions.

These tests types can be used in conjunction with each other. They can also be re-arranged using the hover-menu along the left side. They can be cloned or deleted using the buttons along the right side when a test is selected.

Input/Output comparison tests

A description for the test, like what it tests, can be entered here in the test case description: 

Output tests also allow setting the comparison method.

More compare options appear below that dropdown for ignoring case and whitespace. This is also where the timeout can be changed.

All tests default to a timeout of 10s. When the timeout is exceeded, the test will report a failure due to that timeout. This is useful for indicating infinite loops, or very long running processes. The minimum timeout is 5s and the maximum is 60s. If your timeout appears blank, it is set to 30s. 

Output tests can pass input into a learner's workspace and check the output. However, input is not required to create an I/O test.

The following Python code asks for input and then reports an output.

def color_temp(color):

    # Check if the color input is in the list of warm colors

    if color.lower() in ["red", "orange", "yellow"]:

        return "Warm"

    # Check if the color input is in the list of cold colors

    elif color.lower() in ["blue", "green", "purple"]:

        return "Cold"

    # If the color is not in the list of warm or cold colors

    else:

        return "Invalid color"

# Prompt the user to input a primary color

user_color = input("Enter a primary color: ")

# Output the temperature classification of the color

print(color_temp(user_color))

An I/O test would send the applicable input color and the output would check against it.

Here are two possible I/O tests:
Input: black
Output: Enter a primary color:

Input: blue
Output: Cold

At the bottom of the I/O tests are three accordion menus with more options.

Advanced options allows you to create a custom compile/run, and if the student output should come from the output entered above or an output file.

The default file set in the workspace will compile/run and the output will come from this test, but a custom compile and run can be set instead.

Feedback Options is where various visibility toggles for the input/output/feedback can be set.


Files Options let's you change what files should be included for this test. You can also add and edit files necessary for your test that you do not want included in the workspace. By default all files in the workspace will be included.

Unit tests

Unit tests will default to the most applicable testing framework for the language selected for the IDE. The dropdown contains options for other frameworks.

More in-depth info about unit tests is available here: Creating Unit Tests

The unit test can be edited as needed. Alternatively, a test can be uploaded using the "Choose files" button, including dragging and dropping onto the button.

The default test cannot be renamed or deleted, but, depending on the language, the content of that file can be deleted or your test can be referenced from the default test. For instance, in Java you could upload your file as an additional file with in the unit test and have the default test file "zyLabsUnitTest.java" instantiate an instance of the class that performs the unit test in their uploaded files.

Other files can also be added or uploaded as well, like a data set to reference in the unit test. 

The following C# code asks the user for four things and reports one thing in common.

using System;

class Program

{

    static void Main()

    {

        string[] likes = new string[4];

        for (int i = 0; i < 4; i++)

        {

            Console.Write("Enter thing number {0} that you like: ", i + 1);

            likes[i] = Console.ReadLine();

        }

        

        Random rand = new Random();

        int index = rand.Next(4);

        Console.WriteLine("I also like {0}!", likes[index]);

    }

}

The same Feedback options from the output test, and similar File options, are visible in the accordion menu below the unit test. Notice the 10s timeout, the same as the default for I/O tests, is editable here.

See this article for more information about unit tests.

Custom bash tests

Custom bash tests allow you to write a shell script and define your own logic for passing/failing tests and assigning points. You can include special compile and run commands to test how code will behave in different circumstances. You can include additional files with the test and run whatever tools you need to evaluate learner code similar to a unit test.

The results are written into the test's RESULT file, and debug output is sent to the DEBUG file. You can also write custom feedback to the FEEDBACK file to be shown to the student. Some examples are provided below. 

Basic Output Test - Python

# Exit immediately if a command exits
set -e

# Run code and show any errors in DEBUG
python3 main.py 2> DEBUG 2 1> STUDENT_OUTPUT

# Identify expected output
echo 'Hello World!' > EXPECTED OUTPUT

if diff STUDENT_OUTPUT EXPECTED_OUTPUT >/dev/null ; then
    echo 'p' > RESULT
    echo 'Test passed!' >> DEBUG
else
    echo "np" > RESULT
    # Show the expected output to the student
    icdiff STUDENT_OUTPUT EXPECTED_OUTPUT >> DEBUG 2>&1
fi

Basic Output Test - Java

# Exit immediately if a command exits
set -e

# Compile code and show any errors in DEBUG
javac Main.java >> DEBUG 2>&1
# Run code
java Main > STUDENT_OUTPUT

# Identify expected output
echo 'Hello World!' > EXPECTED OUTPUT

if diff STUDENT_OUTPUT EXPECTED_OUTPUT >/dev/null ; then
    echo 'p' > RESULT
    echo 'Test passed!' >> DEBUG
else
    echo "np" > RESULT
    # Show the expected output to the student
    icdiff STUDENT_OUTPUT EXPECTED_OUTPUT >> DEBUG 2>&1
fi

Valgrind Test

echo 'Compiling code' >> DEBUG
g++ -std=c++17 -Wall -Werror main.cpp -o a.out >> DEBUG 2>&1
EXIT_CODE=$?
if [ $EXIT_CODE -ne 0 ]; then 
    echo 'np' > RESULT
    echo 'Code did not compile' >> DEBUG
    exit 0
fi

echo 'Running Program' >> DEBUG
./a.out >> DEBUG 2>&1
EXIT_CODE=$?
if [ $EXIT_CODE -ne 0 ]; then 
    echo 'np' > RESULT
    echo 'Program did not run properly' >> DEBUG
    exit 0
fi

echo 'Checking for Memory Leaks' >> DEBUG
valgrind --leak-check=full -s -q --error-exitcode=12 ./a.out >> DEBUG 2>&1
EXIT_CODE=$? 
if [ $EXIT_CODE -eq 12 ]; then 
    echo 'np' > RESULT
    echo 'Memory errors detected!' >> DEBUG
    exit 0
else 
    echo 'p' > RESULT
    echo 'No memory errors detected!' >> DEBUG
    exit 0
fi

Manual Tests and Deductions

There are also options to manually review content and add or deduct points based on that manual review. Learn more about manual tests here.

Model Solution

Model solutions are a great way to verify the test bench works properly with an ideal solution. Click on the Model Solution tab, then "Create Model Solution" to begin.

A default model solution will be created based on the existing template. Edit as needed, and click "Run Tests" to verify they work as expected.

An expected output based on the model solution can also be selected from inside an I/O test.