Projects
Working on Your Own Computer
If you've installed Ubuntu to dual-boot or if you're running Ubuntu inside a virtual machine, there may still be some tools installed in the lab that have not been installed on your machine. To address this issue, please download the script given below:
Once you've downloaded the script, use the terminal to navigate to the directory that contains it. From there, make the script executable and then run it with administrator privileges. The commands will look something like the following:
chmod +x updates.sh sudo ./updates.sh
You will be required to enter your password. If you're connected to the Internet, the script will attempt to update some of the software on your computer. A relatively small amount of software is needed for this course, but it still might take several minutes to install, depending on your Internet and computer speeds. It's not a bad idea to restart Ubuntu after this installation.
Building and Testing Projects
Every project and assignment has a structure with the source code and a Makefile provided at the top-level directory. To build the project, simply type make at the command line.
Every project also has a tests directory containing unit tests, integration tests, the input for the tests, expected output, and scripts to run all the tests. In the top-level directory for the project, you can run all the tests by typing make test.
Within the tests directory, there are a number of important files and subdirectories:
- tests/public.c
You can modify this file to test functional units of the program rigorously, with both acceptable input and intentionally bad parameters (although the types must be correct). For instance, you will need to include tests that pass NULL pointers to ensure that functions handle such arguments without crashing. For more information on how to write unit tests in the Check framework, visit the Check home page. - tests/itests.include
This configuration file specifies command-line arguments that will be used for integration testing. You can modify this file to add test cases for both good and bad command-line arguments. - tests/expected/
This directory contains text files with the expected output for integration tests. When you add test cases to itests.include, you must also create a corresponding .txt file in this directory. Since diff is used to compare the output of your program to the contents of the .txt file, they must match verbatim. If there's even a single extra space, the test case will fail. - tests/inputs/
This directory contains files that can be used as input to the projects. In your itests.include arguments, these files should be referenced with the inputs directory. - tests/Makefile, tests/integration.sh, and tests/testsuite.c
These files are the drivers for the testing infrastructure. You should not need to modify them, but you are encouraged to read through them.
This description of building and testing procedures is based on Testing Procedures for CS 361 by Michael S. Kirkpatrick. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
Turning in Projects
All projects are team projects in this course. For each project, all students must form teams of two (or three in the case of an odd number of students). Students are permitted to select their own teams; however, no two students may partner up for more than one project. In other words, each team will be different for each project. Students should select their teams through Brightspace.
Teams are responsible for dividing their workload. Except under extreme circumstances, all members of the team will receive the same grade for each project. The files for each project should be zipped up and uploaded using Brightspace before the due date. Projects must not be stored in a public folder. If the project is late, the group will receive a score of 0. If the project does not compile, the team will receive a score of 0.
Projects will be graded based on the following criteria:
- Correctness
Finding the right answer - Formatting
Displaying the right answer according to instructions - Style and Documentation
Producing readable code with appropriate comments
Unit tests will be provided for each project, so students will have a good sense of how they've done when they turn it in.
Late projects will not be accepted, with the following exception. Each team has 3 grace days. These grace days may be used together or separately to allow a 24-hour extension of the project deadline per grace day. A team wishing to use a grace day must inform the instructor via e-mail before the normal deadline. Both students in the team will have the appropriate number of grace days deducted. If the members of a team have different numbers of grace days available, the team will be treated as if it has the maximum number of grace days of any of its members.
Under no circumstances should a team member look at the code written by another team. Tools will be used to detect code similarity automatically.
