Due: 4/12 11:59pm
By the time you have finished this lab, you should have demonstrated your ability to use a simple Test-Driven Development framework (similar to last week's lab, and possibly from CS16 and 24 labs) to write the methods of a simple C++ class with getter methods.
2 Getting Started
This lab may be done solo, or in pairs.
Before you begin working on the lab, please decide if you will work solo or with a partner. If you decide to work with a partner, read the Working in pairs section of the course webpage.
Once you and your partner are in agreement, choose an initial driver and navigator, and have the driver log into their account.
3 Copying some programs from my directory
Visit the following web link—you may want to use "right click" (or "control-click" on Mac) to bring up a window where you can open this in a new window or tab:
You should see a listing of several C++ programs. We are going to copy
those into your
~/cs32/lab2 directory all at once with the following
cp ~emre/public_html/cs32/code/lab2/* cs32/lab2
Note: If you get the error message:
cp: target '/cs/student/youruserid/cs32/lab2' is not a directory
then it probably means you didn't create a
yet. So do that first.
* symbol in this command is a "wildcard"—it means that we want
all of the files from the source directory copy be copied into the
destination directory namely
After doing this command, if you
~/cs32/lab2 and use the
ls command, you should see several files in your
directory–the same ones that you see if you visit the link
If so, you are ready to move on to the next step.
If you don't see those files, go back through the instructions and make sure you didn't miss a step. If you still have trouble, ask your TA for assistance.
4 Step 2: Understanding the Starting Point Code
4.1 Understanding the Makefile
In this week's Makefile, you'll see a few things:
CXXFLAGS = -Wall -Wextra -Wno-unused-parameter -Wno-unused-private-field # Change to this before final submission: # CXXFLAGS = -Wall -Wextra -Werror
These are the "flags" used when compiling. The
-Wno-unused-parameter -Wno-unused-private-field flags are used here
because we are doing "test-driven development", and you are starting
with "stub code".
Stub code is code that is the minimal amount of code needed to both (a) compile and (b) definitely fail all of the tests. It makes sure that your tests report failure when the code is definitely broken. It is a way of "testing the tests."
In stub code, you sometimes have unused parameters, and unused data members (a.k.a. private fields). We want the compiler to shut up already about those, because we expect that.
Before you turn in your code though, you want to change up the compiler flags to say: if there is any problem at all, tell me about it. Treat warnings as hard errors that prevent compilation. So, be sure to change this flag as indicated in the comments before you make your final submission.
Side node: We use
-Werror in this class because we use the same
compiler version throughout the class. In a real-world production
environment, this is not good software engineering practice: when you
update your compiler, the compiler may emit different warnings you did
not account for; or if somebody else is trying to compile your code
with a different version of the compiler, they may get unexpected
warnings turning into hard errors.
BINARIES=testStudent1 testStudent2 testStudent3
This is a variable that contains a list of the three test programs that
we are running this week to test your code. Note that the variable
BINARIES is used in several places in the Makefile:
- In the
all:to say that by default, we want to
makeall of these executable programs (i.e. binaries).
- After tests: to say that we want
make teststo depend on those binaries being compiled and linked—note that we then run each of them in turn to actually test our code.
- In the
clean:rule to say that
make cleanshould remove all of the binaries in addition to removing all of the .o files.
There are other things in the Makefile such as the
$^ syntax, and the
$@. Notice all of these things, and figure out how this Makefile
works. A good reference explaining some of the Makefile syntax seen here
Note that this focuses on compiling C programs, but is still (mostly)
relevant for our purposes.
4.2 Understanding the Student class:
Then, look over the
You'll see that the
Student.h file contains the specification of a
simple C++ class to represent a Student. We will be using this class in
a future lab as the basis of a Roster of students, and we'll be working
with various sorting and hashing algorithms on this Student class.
For this week's lab though, we just want to focus on simple test-driven development of the constructor, getters and a toString function.
The only file this week where you will be making changes is
4.3 Understanding the tests:
What you should do next is to look through the test cases in
files use a simple test-driven development framework defined in
Look over these files and understand how they work. Then, type
make tests to compile and run all of the tests.
You can also type, for example,
make testStudent1 and
to make and run these tests one at a time.
When you are ready, start editing
Student.cpp, replacing the stubs for
the constructor first, and then each of the stubs for the other
4.3.1 Tip: A special note about the
Note that in the case of the
toString function, a correct
implementation is already provided, but commented out.
This example can be used as the basis for writing similar
functions in future labs. This is the only time we will provide an
example of this technique, so please study it well, and if you have
questions about it, please ask.
5 Step 3: Make all the test cases pass
Make the test cases pass by replacing the stubs in
working code. This is the only file you should need to change.
6 Step 4: Checking your work before submitting
When you are finished, you should be able to type
make clean and then
make tests and see the following output:
-bash-4.2$ make tests clang++ -Wall -Wextra -Wno-unused-parameter -Wno-unused-private-field -c -o testStudent1.o testStudent1.cpp clang++ -Wall -Wextra -Wno-unused-parameter -Wno-unused-private-field -c -o Student.o Student.cpp clang++ -Wall -Wextra -Wno-unused-parameter -Wno-unused-private-field -c -o tddFuncs.o tddFuncs.cpp clang++ testStudent1.o Student.o tddFuncs.o -o testStudent1 clang++ -Wall -Wextra -Wno-unused-parameter -Wno-unused-private-field -c -o testStudent2.o testStudent2.cpp clang++ testStudent2.o Student.o tddFuncs.o -o testStudent2 clang++ -Wall -Wextra -Wno-unused-parameter -Wno-unused-private-field -c -o testStudent3.o testStudent3.cpp clang++ testStudent3.o Student.o tddFuncs.o -o testStudent3 ./testStudent1 Testing class Student... PASSED: s1.getPerm() ./testStudent2 Testing class Student... PASSED: s1.getLastName() PASSED: s1.getFirstAndMiddleNames() ./testStudent3 Testing class Student... PASSED: s1.getFullName() PASSED: s1.toString() -bash-4.2$
At that point, you are ready to try submitting on the Gradescope system.
7 Submitting via Gradescope
The lab assignment "Lab 2" should appear in your Gradescope dashboard in CMPSC 32. If you haven't submitted anything for this assignment yet, Gradescope will prompt you to upload your files.
For this lab, you will need to upload your modified file
Student.cpp). You either can navigate to your file,
"drag-and-drop" them into the "Submit Programming Assignment" window, or
even use a GitHub repo to submit your work.
If you already submitted something on Gradescope, it will take you to their "Autograder Results" page. There is a "Resubmit" button on the bottom right that will allow you to update the files for your submission.
For this lab, if everything is correct, you'll see a successful submission passing all of the autograder tests.
Remember to add your partner to Groups Members for this submission on Gradescope if applicable. At this point, if you worked in a pair, it is a good idea for both partners to log into Gradescope and check if you *can see the uploaded files for Lab 2.