Test cases are a great tool for students relatively new to the discipline. Since I teach CS50 AP, my students have access to the command-line tool
check50, which they can run for nearly all the programs they write at the beginning of the year.
For my students who are new to the discipline, this helps them understand the need to read the problem specification thoroughly since each test case connects directly to something they are asked to implement. It's a relatively simple tool: if a test passes, they'll see a green
:); if it fails, a red
:(; if something unexpected, a yellow
As the difficult and the size of the programs scale, students have to stop relying on the tool and instead have to test their code thoroughly based on a careful, thorough reading of exactly what they are being asked to do. Scaffolding in this way shifts the onus over the course of the year: they are given each test case in the beginning, but as the year progresses, it is more and more their responsibility to test their code for all possible inputs. This gradual transition works well. Here's how CS50 explains it when students reach the first assignment -- one which uses random numbers -- for which there is no
When ready to check the correctness of your program officially with
check50...well, you can’t. Reason being that the way the staff
solution generates random numbers might in fact be different from your
own, even though both do properly generate sets of random numbers.
It’s up to you to determine that your program produces:
the correct number of pseudorandomly generated numbers,
each of which is greater than or equal to 0 and also less than (and
not equal to)
that if your program is run with the same seed value multiple times,
the list of numbers it generates is identical from run to run.
Not having access to
check50 for this problem is actually a good
thing. It’s a bad idea to get into the habit of testing your code with
check50 before testing it yourself. (And definitely don’t get into an
even worse habit of only testing your code with
check50!) Suffice it
check50 doesn’t exist in the real world, so running your code
with your own sample inputs, comparing actual output against expected
output, is the best habit to get into sooner rather than later.
Truly, don’t do yourself a long-term disservice!
As a final point on this topic,
correctness (passing each test case) is only one of four axes I use to assess their work. I also look at
scope (attempting to implement all aspects of a program),
design (efficiency of logic/algorithm(s) in a program), and
style (readability vis-a-vis variable names, indentation, etc.). If you only grade on getting the code right, then I could see not providing test cases for every test case. However, if there is a bigger picture to assess in terms of code style and design, then I see no problem in giving as much information up front in order to aid student learning.