Skip to main content
All CollectionsTests / AutogradingWriting tests
Defining an Environment: Example
Defining an Environment: Example

A walkthrough on creating your codePost environment

Vinay avatar
Written by Vinay
Updated over 4 years ago

The “Environment” is the set of specifications that are used to instantiate the container in which tests are run. 

Let's go through an example of creating an environment for our java course. 

Getting Started

Let's first navigate to the Assignment -> Tests page and click "Create"
​

Language

Now we need to specify a language: When you specify a language, all the basic tools and binaries to run code in that language are installed in the container. This language should be set to the language of your student’s code. 

When choosing a language, you can pick either a "default language", which we've pre-built the environment for, or a "custom build", if you need more flexibility. The default languages supported are: c/c++, java, python2, and python3. If you want to learn more about building a custom container, check this article. 

Dependencies

Dependencies are external packages that are required in your environment. When you specify a dependency, that packages is installed in the container.  Currently this is only supported for python (installed via pip). For other languages, you’ll need to include the dependency as a helper file (see below). 

Let's click Create to specify our environment. When it's created, we'll see options to set our runscript:

Runscript

A runscript is a bash code snippet that should be run before any tests. For example, our pre-populated default java run script goes through our root directory and compiles all java files. 

if [ $(ls -A *.java 2>/dev/null | wc -l) != 0 ] ;
then
    javac -cp . *.java -d .
fi

Note: When you “run all” tests on a submission, the run script is only run once (before the first test is run). 

We can change our run script if we want to, but this default compilation script looks good for our assignment. Let's move on to defining helper files. 

Helper Files / Custom Dependencies

Helper files are any files that you would like to access in your tests. There are two types of helper files:

  1. Files that a students' code needs to access (e.g., Libraries and Helper classes) For example, if your course has a custom StdIn.java that students’ code uses, you can include that as a helper file instead of having each student include the file in their submission

  2. Files that your tests need to access, such as Test data (data files to input to student code) or Test classes (helper classes that you've already written that you want to upload)

In our case, our students' code uses some special StdIn.java  and StdOut.java  files, so let's upload them:

We can upload nested directories, if we'd like, and can edit the text inline in the interface after we upload. 

Finally, let's upload our Solution Code.

Solution Code

Solution code is the set of files that constitute a “correct submission”. In the test definition process, you have the option of running tests on “Solution code”. When you choose to do that, it will run the tests with these files in the same container. 

A typical test writing workflow will be to Upload solution code → Write a test → Run the test → Update test or solution code → Run again. 

Let's upload an example of a correct Calculator.java. Like Helper files, we can upload directories, and edit them in the interface. 

 

Did this answer your question?