If this is your first time reading through the testing guide, please read the full summary below.
Most of what you need is under the marking directory in the course account. From here you can go into a specific assignment. The convention is to label the assignment directories aXX, where the XX is the number of the assignment. Under each assignment directory should be a test.0 and a test.pt directory.
There may also be some test.0.something and test.pt.something directories. The "something" can be any string, and is just used as a label. These directories contains test results for students. One level down will be directories labeled with student's quest ids. These contain the results for that individual student.
Descriptions in Point form:
1. test.pt - This directory contains all basic tests setups. Basic tests are created before the assignment is released to students. These are used to help students catch simple errors.
2. test.0 - Similar to test.pt, test.0 contains all correctness tests setups. These tests are used to fully test and grade a student's submission. All setups in test.0 need to be finished before the assignment is due (or at last collected and tested).
3. Computemarks (click on this link for more information) - This is the initial script that is run when we talk about "running tests" through rst. bittersuite (/in tests) are run from here. This should not need any modification.
4. options.rkt (click on this link for more information) This tells the script which language to use, which file to load, etc.
5. Computemarks-postprocess - This is the last script that RST runs after running bittersuite (the in/ directory tests). The filenames at the top of computemarks-postprocess file need to be updated for every assignment. Note that if students submit too fast while basic tests are running, computemarks-postprocess complains and lets them know that tests were interrupted.
6. test.rkt (click on this link for more information) - This is the place where put the actual tests.
7. provided (click on this link for more information) - This is the place where all the scripts and helper files we use go.
8. config.ss (click on this link for more information) - This file specifies options that will apply to this entire BitterSuite run.
9. in - This contains directories for every question on the assignment and is where the tests go.
---------------------------------------------------------------------------------------------------------------------------------------
Some Information in more detail:
One level into test.0 there is a provided and an in directory, as well as some other files. The header file contains the text that will show up at the top of all test results for the assignment. Other files not listed in the diagram should not need any modification.
Regarding provided, for basic details on including libraries see this section link. For more in-depth details, or if you are running into errors, see this section link.
Regarding "in", within each question directory will be directories starting at 001 going up to the last test that you want to write for a question. These directories contain a test.rkt file which is an individual test for that question. Basic tests will usually only need just one test, so there will only be a 001 for that question. Stepper questions have a different format, see this section link for more information.
More details on this script can be found on the MarkUsScripts page
(result (equality-operator (student-function our-test-input) expected-output)) (expected true/false)
;; You can also have format like the following. However the first one is prefered because it avoids revealing our test(s).
(result (student-function our-test-input)) (expected expected-output)The expression in the result line will be evaluated in the language chosen in the options file. The value produced will then be compared to the value in the expected line, using the function equal?. If these two values are the same, and there were no errors while evaluating any expressions, the submission will pass the test. Unfortunately, this is not a built-in form in Racket, so you can only check them in check-expect form or use rst to actually run them on the server. You can still call other Racket functions in the test case, even something like a cond with multiple cases depending on what the student's function does. There will be more tips on writing tests in the basic and correctness test sections. Note that for steppers, test.rkt is slightly different. You can refer to this StepperQuestions for more details. Also note that you are not limited to only use expected and result in test.rkt. You can refer to this page BitterSuiteScheme for more information.
More information on BasicTests and CorrectnessTests can be found on their respective pages.
In CS135 it is common practice to ban certain built-in functions from being used, more information on how to do this can be found on the BanningFunctions page
When setting up tests, sometimes issues may come up, information on these problems can be found on the SpecialCases/CommonIssues page
Once you have completed a test setup for an assignment, it is very important that you look over your work to make sure that it has been done correctly, and that there will be no issues once students start submitting. For more information on how you can look over your work, you should check out the ProofreadingTestSetups page