summaryrefslogtreecommitdiff
path: root/c2prj2_testing/README
diff options
context:
space:
mode:
authorHaidong Ji2022-04-15 15:51:30 -0500
committerHaidong Ji2022-04-15 15:51:30 -0500
commit442a49ad5a48d417345959b903ae6a6d32d55759 (patch)
treec7127bb497e5e439018b1915e0136eec2c9cb124 /c2prj2_testing/README
Great C programming funHEADmaster
Excellent fundamentals and displine training, many tools and techniques exercises: gdb, emacs, valgrind, git
Diffstat (limited to 'c2prj2_testing/README')
-rw-r--r--c2prj2_testing/README122
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.