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 is 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. 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, either click on an existing custom section, alternatively click "Add a zyLab" or "Create section" at the bottom of the chapter.

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


When inside a custom section, click "Advanced zyLab" or "Import" to add one to the page. Any number of labs can be added to a section.

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 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 file tree icon to open the file tree to create files and folders, re-arrange files, as well as upload, download, rename, duplicate, mark as read-only, and delete files.

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.

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.

History

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

Work can be checked keystroke-by-keystroke by clicking the forward and back arrows, or clicking anywhere in the timeline. 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. Scroll through the timeline and click the file you'd like to switch to in Files to continue moving through the timeline with that file active in the codepad.

When moving through the timeline, clicking Restore File will open a prompt to revert the code to the 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 creation of a new file, and restoration of the Main.py 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 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, but a drop-down menu can be toggled on in the workspace settings to allow the selection of other 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 submit side

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

2. Sync All

    a. Indicates if 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

If the IDE is disconnected from the internet, the connection indicator appears 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 Comment

Ctrl + F - Find

Ctrl + G - Go to line

Ctrl + , - Make Font Smaller

Ctrl + . - Make Font Larger

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 changing by clicking in the Unit Testing Framework dropdown, and selecting another test type, like JUnit 4.

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 menu along the right side.

Input/Output comparison tests

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

Output tests also allow setting the comparison method.

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 line above or an output file.

By default the default file set in the workspace will compile/run and the output will come from this test.

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 allows changing the framework.

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 and the default removed via the menu above the test. 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. For this example, a unit test is a good solution for autograding.

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.

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.

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. 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.