TDD

Today and yesterday we spent time working on the poker project, the assessment 02 practice, and learning SQL queries for database oriented work coming up this week. I am glad that we are moving past a bit from the standard ruby flavors that we have been doing for a while now and tackling new, different things.

Doing this TDD style has been interesting. While I cannot say that it is my cup of tea, it makes me very admiring of those who actually do it. Doing TDD meant that I could not write actual code without writing the test. I ended up writing too many tests or tests that did not matter. Then I had to go back and modify the tests. I would have an idea to go and hack out a method but because I was not sure how it would turn out, I could not write the test for it first. It was a challenge.

The poker project has been interesting and fulfilling. The practice for assessment 02, which is going to test our knowledge of object oriented programming. That was about building a blackjack game. Taking that practice actually helped me a lot in learning how to handle the poker project. Cards act the same way across both games (with the exception of a few values) and I was glad to find that the way that I did it and the way Ned did it were quite similar. The challenge between the blackjack game and the poker game is the concept of hands. Different classes of hands matter. A straight beats trips and is beatened by a flush. However, you cannot just write code that recognizes a straight or trips or whatever because there are situations when you have to delve down into the high cards to determine who wins in a situation where two people have the same class of winning. This felt to me like it would be a huge duplication of the code, especially if you cannot set up the recognition of the classes easily. The way I eventually settled was to create a series of instance variables (pair?, high?, trips?) that would identify when someone has a certain class. Some of these were variables that would be flipped. Others like straights and flushes needed more lines and I wrote them as their own methods. Whatever the result, what came out was a boolean true or false.

Then there was a method that I wrote that does a check to see if it was ever really needed to delve into the individual cards. If someone has a straight and the other guy has a flush then there was no point in wasting the computer’s time. However, if this is not the case then you have to break out the cards. I wrote method that returned the hand in particular and another that would compare them. These are all then tucked into a generic, single method called ‘beats?’ which is kind of like the interface for them all. I am not sure if this is the best way to do it, but I felt that it was ideal because it exposes only 1 method to the rest of the classes like Player and Dealer and Deck. They do not have to worry about whether or not that there are a full suit or whatever. They just have to know if the hand beat the other.