Test-driven development
Goals
This assignment has the following goals:
- Learn how to tackle a programming assignment incrementally.
- Learn the basics of test-driven development
- Prepare to do HW04.
Overview
In this class—and virtually all future programming courses—the only viable way to build up a project is to build it incrementally, while testing and re-testing your implementation at every step. For many students, it can take a long time to learn this valuable lesson.
This is a short assignment, but an important one. If you give this some thought, and then apply it to HW04 and all future assignments, you will find that programming—and ECE 264 as a whole—is a lot more fun.
How to spend less time debugging (and more time enjoying the sunshine)
Let's illustrate t by example. Consider two approaches to doing HW04:
-
Student X reads the description, thinks it through, and then codes up the entire solution. Then, they write all the tests at once. When they run the tests, there are dozens of compiler warnings and errors. After solving those, they find that none of the code works. They debug one issue after another until finally, everything works*.* This is optimistic. Sometimes, they miss the deadline.This chart shows Student X's time:=read =add new code =test/debug =make tests
-
Student Y reads the description, thinks it through, and then starts on a very small amount of functionality (e.g., printing an empty string, or a single character). Before they write any code in their
mintf(…), they put a line in their test_mintf.c and the expected output in their test_mintf.txt. Then, they add just enough code to theirmintf(…)to make it pass that first test. Then, they add another test for little more functionality (e.g., printing an integer by itself withmintf("%d", 768336)). After adding the test, they add just enough code to theirmintf(…)so that it passes that test, and the previous tests. It still doesn't do everything it needs to, but it does a few things perfectly, and there is no broken code.Each step in the process is short—about 2 minutes to add a test, and 5-10 minutes to augment theirmintf(…)implementation code—so their code is never broken for more than about 10 minutes at a time. Once they've added all of the required features, the code works perfectly. There is no major debugging step at the end.This chart shows Student Y's time:=read =add new code =test/debug =make tests
Student X and Student Y spend the same amount of time reading, coding, and making tests. The difference is that if Student Y has a bug, it must have been introduced no more than about 10 minutes ago, since the code is never broken for more than about 10 minutes at a time. When Student X has a bug, it could be practically anywhere, so each bug takes much longer to diagnose and fix.
Although this is just an illustration, it is based on our observations of students in past semesters, our own experiences, and a well-established software engineering process. Our version of TDD is simplified, but the core process is the same.
Test-driven development
To begin, first create an empty test code file (e.g., amain(…) with just one line:
return EXIT_SUCCESS;) and an empty output file (e.g., empty text file).
Make sure your testing process is working by simply running the test code file
and verifying that the output matches the test output file. (Commands were given in
HW02.) Then, proceed as follows:
- Create test. Choose the smallest/easiest piece of functionality that you can add to your implementation file (mintf.c). Add a test to your test code file (test_mintf.c) and the expected output in your test output file (test_mintf.txt).
- Add code. Write just enough code so that the new test passes. Your impelementation won't be complete yet, but everything you've written so far should work.
- Test. Check that your code now passes all of the tests written so far. If anything doesn't work, fix it before you go on. At the end of each cycle, 100% of your code should be working, even though some parts for other features may not be written yet.
Instructions
Read the instructions for HW04 before you proceed.
Create a file called plan.c with only a main(…)
function.
In the main(…)
function, write out a series of at least 10
stages that you will use to build your HW04
incrementally using TDD. Each stage must be in the following form:
// Test ## TEST_CODE // Expect: "EXPECTED_OUTPUT"
These stages will trace the steps from beginning your HW04 to finishing it. Each stage adds a small amount of required functionality that was not present in previous stages.
Later, when you implement your code for HW04, your code should never be broken for more than 10-15 minutes at a time, because you will be writing it in very small increments. After each stage, you will get your code completely working—for that subset of the functionality.
Assume that you are starting with a working
print_integer(…). Thus, you do not need to
have steps for testing internal aspects of
print_integer(…). You are planning the development
of your mintf(…) function
for HW04.
More detailed criteria are given below under Requirements.
Note: Your plan.c will not be compiled or run by us. Instead, it is just serving as a sort of document for you to communicate your planned stages to us. Yes, this is weird.
Definitions: For purposes of these instructions, “implementation code” means your mintf.c; “test code” means your test_mintf.c; “test output” means your test_mintf.txt; and “test” means a small section of your plan.c (most likely in the main(…) and the corresponding snippet in your test_mintf.txt, which together can be used to verify that some aspect of your program works according to the specification.
Requirements
- One file is required: plan.c
- Your plan.c must contain a
main(…)containing ≥10 stages meeting the following criteria:- Stage 00 is an empty test to check your testing framework. It should always pass.
- Tests for all stages from 0 to n pass with the implementation for stage n. In other words, the changes you make in stage i will not require breaking any of the tests associated with previous stages.
- Implementation code in stage i would fail the tests for stages i<1.
- Implementation code in stage i+1 will be different from code in stage i.
- Implementation code in stage n+1 will add required functionality that was not in stage n.
- Implementation code in stage n+2 has more sloc* than implementation code for stage n.
* sloc = “source lines of code” (excluding comments and blank lines)
-
Altogether, the tests will comprehensively test your final implementation of
mintf(…)for HW04. In other words, any implementation ofmintf(…)that passes all of your tests must be working perfectly.
- Each stage must be in the following format:
// Test ## TEST_CODE // Expect: "EXPECTED_OUTPUT"
- Special for this assignment:
- You may copy anything in the screenshot, including stages 00 and 01. The rest of your test cases must be your own.
- Your code does not need to compile or run for this assignment (HW03).
While these requirements may initially sound complex, they are not. If you are following the spirit of the TDD method, all of this will almost certainly happen naturally.
Scoring
This assignment will be human-graded. Scores will be based on how well your steps follow the requirements.
Submission
Submit using the usual command. (See the previous assignments and printed on your reference sheet.)
How much work is this?
This assignment is expected to take 1-2 hours for most students, but you may find that it takes more or less. You will need to read the assignment description for HW04 and think creatively about how you will tackle it.
