Week 12 Class 23 Tue Nov 10 Posted: Nov 10
Announcements
No New Rules
The questions I receive about Project 3 TDD are almost always in the form of general, written hypotheses, such as:
From these rules, it looks like whenever both a URL and a hash are provided, the URL should take priority in determining the final attribute values. And if the disk filename conflicts with either of those, does the priority system always override it? I want to verify whether this hierarchy is intended to be absolute across all inputs.
What is happening is that students are trying to state explanations/new rules. This, in general, is not useful. We already have the rules. We do not need an annotated version. Besides, I have to work to understand what you really mean, and I am often unsure that I understand correctly.
What I rarely get is a test case where the student wants to know if they have the correct output.
This is useful. I can answer this easily.
This applies to much more than this problem. Instead of asking if your wordy, difficult-to-understand interpretation is correct, create the test and ask about that. We already have the problem of difficult-to-understand original rules. Don't make it worse.
Mock Clock III
360000? or 3600? These are magic numbers, i.e., numeric literals whose meaning is not clear from the code. In a large project, how would I remember this? What I can easily understand is:
So why not use this formula? Why did I see people using a calculator for this. The C++ compiler (and the compiler for almost any real language) can compute this at compile time. Why not take advantage of this?
Why is this important? Because we need to find things in our code. And if you were looking for 100 hours, you would search for the value 100. And when you use cryptic things such as 360000, that doesn't work. Write the program as much as possible using concepts from the problem domain. This includes naming, literal values, strings, etc. Here is an adapted example from the Linux kernel:
So write these clearly as factors. Let the compiler do the math.
Redirecting an Output Stream
Testing the output of code to std::cout (standard output) or std::cerr (standard error) is not immediately testable in a unit test. We need to "grab" this output and store it in a std::string so we can verify the result. The way to do this is to redirect the output to a string. The following program is an example of how to do that:
Class
Unless stated otherwise, all exercises are due by 4 pm on Wed Nov 11