1 files changed, 122 insertions, 0 deletions
diff --git a/c2prj2_testing/README b/c2prj2_testing/README
new file mode 100644
index 0000000..17a11a6
--- /dev/null
+++ b/c2prj2_testing/README
@@ -0,0 +1,122 @@
+The second part of this course's poker project is to write
+test cases for what you will do in the next course.
+
+In particular, one of the things you will do in your
+project in Course 3 is write the code to evaluate
+which poker hand wins between two complete hands.
+This involves writing all the code to figure out
+what kind of hand (straight flush, full house, etc.)
+is in a hand, and which 5 cards ultimately make it up.
+For example, if one hand is
+
+0c 0s 8s 7d 6d 6s 5c
+
+and the other is
+
+Js 0s 8s 7d 6s 5c 4c
+
+your code in the next course will figure out that
+the first hand has two pairs (10s and 6s) with an 8
+as the tie-breaking card (called the "kicker"),
+and that the second hand has a straight (8 7 6 5 4).
+The straight beats the two pairs, so hand 2 wins.
+
+We have provided you with test-eval, which reads
+a file containing lines with one pair of hands
+on each line and prints out the details of evaluating
+that hand.  Each line has one hand, a semi-colon,
+then the other hand, so the input for the above would
+be:
+
+0c 0s 8s 7d 6d 6s 5c; Js 0s 8s 7d 6s 5c 4c
+
+We have put this in example.txt.  If you run
+
+./test-eval example.txt
+
+Then you will get the following output:
+
+Hand 1:
+--------
+0c 0s 8s 7d 6d 6s 5c 
+ - No flush
+ - The most of a kind is 2 of a kind (at index 0 / value 0)
+ - Secondary pair at index 4 (value 6)
+ - evaluate_hand's ranking: TWO_PAIR
+ - 5 cards used for hand: 0c 0s 6d 6s 8s 
+Hand 2:
+--------
+Js 0s 8s 7d 6s 5c 4c 
+ - No flush
+ - Straight at index 2
+ - The most of a kind is 1 of a kind (at index 0 / value J)
+ - No secondary pair
+ - evaluate_hand's ranking: STRAIGHT
+ - 5 cards used for hand: 8s 7d 6s 5c 4c 
+Comparison : 
+--------------
+Hand 2 wins!
+============================
+
+You can see that for each hand, this program not only prints
+the overall ranking (STRAIGHT, TWO_PAIR, etc), but also the
+results of various parts of the evaluation that went into
+the decision: Was there a flush?  Was there a straight (if
+so, where?) How many of a kind were there? etc.
+
+As with other testing assignments, we have written
+some broken implementations and placed them in
+/usr/local/l2p/poker/
+
+Your goal is to write testcases in tests.txt
+that test this problem sufficiently to identify
+the problem in each broken implementation we provided.
+
+You can use the run_all.sh script that we provided
+to run your test cases against all implementations.
+
+Here are some hints:
+====================
+
+ - Straights are tricky. Think about various ways that a programmer
+   might mess up in finding a straight.  These problems could include
+   both figuring out if there is a straight as well as copying out the
+   cards that make up the straight (or straight flush).
+
+   There could even be an off-by-one bug in where to look for a straight
+   in the hand ("count from 0 to the number of cards in the hand minus
+   [something], call it i.  Check if a straight starts at position i"
+   In such an algorithm, [something] could be off by one)
+    
+ - Think about ways in which a programmer might mis-think about what
+   they need to do.  For example, one might think you can check for a
+   straight flush by checking for a straight AND a flush, but that is
+   not correct (with more than 5 cards, you could have some that are a
+   straight but others of the same suit).
+   
+ - Be sure to just provide simple coverage of the basic cases (each
+   type of hand outcome, etc).
+
+ - The suits are numbers, and can be iterated across )where do you
+   think we iterate over all the suits?).  What if we counted wrong
+   when iterating over the suits?
+
+   
+ - Two pairs have some subtle cases in terms of selecting the right 5
+   cards for the final hand.  Remember from the reading that the way
+   tie breaking works requires the final 5 card hand to be ordered:
+   (larger pair) (smaller pair) (tiebreaker)
+
+ - Think about everywhere the programer could be off-by-one.
+   This might include such things as counting through all the
+   positions in the hand (either missing the start or the end),
+   or being off-by-one in how many cards are required
+   for a particular hand (e.g., only requiring 4
+   cards meet a particular condition instead of 5).
+ 
+ - Note that you may be able to 'game' your way into passing all 
+   the tests locally, but if you do this you won't actually pass the
+   assignment. The only way to pass is to provide good tests.
+
+ - Note additionally that you do not need to use invalid cards
+   in your tests.