Use Test Driven Development (TDD) to create a collection of Ruby classes that would provide the foundation for creating a scrabble game. In this project we will NOT create a full Scrabble game.
- Use Test Driven Development (TDD) to write tests and code in parallel
- Create class and instance methods according to requirements
- Utilize Single Responsibility Principle to reduce code dependencies
- Utilize composition between classes, where appropriate
This is Stage 2 pair project.
From the project root, you should be able to execute all of your specs by running rake. Each Ruby class should be in its own file in lib/, and the entire project should be in a module called Scrabble. You will need to use require, require_relative, include and/or extend to tell Ruby how to work with classes in multiple files.
We will use minitest for this project. This is the same test framework that we've used for your previous project. Your spec descriptions should be meaningful and organized into describe blocks that reflect your intent on how to use the code.
To set up tests for your project, you will need to create a Rakefile and a specs directory. Use a Rakefile from an older project to create this Rakefile. It may be helpful to create a spec_helper.rb file. For reference, look back at our lecture on using SimpleCov and creating spec helpers.
Do not move onto a new tier of requirements until the minimum requirements of the previous tier are complete and your specs are green across the board. Use TDD to drive your development and document your edge cases.
We have provided some boilerplate code for your Scrabble game, in wave-1-game.rb, wave-2-game.rb, and wave-3-game.rb. Running $ ruby wave-1-game.rb will begin a command-line game that uses your Scrabble code. The boilerplate code will break the first time you run it: working through the waves specified below should create a running version of the game. Implementing code to make this game run is not a substitute for TDD or writing tests. It is simply there for you and your pair to reference how the Game may run during each wave, to have better perspective of what your program can do, and to have exposure to legacy code. We fully expect you to create the specified classes below strictly through TDD.
It is possible to implement a valid solution to this project that does not run the game.rb files.
Utilize good pair programming practices. Refer to articles from the Agile Alliance and the Agile Institute if you need a refresher for some best practices. Switch driver and navigator roles often. When there is uncertainity or confusion, step away from the keyboard and discuss, plan, and document on paper or whiteboard before continuing.
- You'll be working with an assigned pair. High-five your pair.
- Choose one person to fork the project repo.
- Add the other person in the pair (who didn't fork) to the forked repo as a collaborator. Instructions here.
- Both individuals will clone the forked repo:
$ git clone [YOUR FORKED REPO URL] - Both individuals
cdinto the dir created. - Both individuals install needed tools via Terminal:
$ gem install simplecov
First, come up with a "plan of action" for how you want to work as a pair. Discuss your learning style, how you prefer to receive feedback, and one team communication skill you want to improve with this experience. Second, review the requirements for Wave 1 and come up with a "plan of action" for your implementation.
- Create a
Scrabblemodule at the project root. - Create a
Scrabble::Scoringclass which contains some sort of data structure to store the individual letter scores listed below. - Create a Spec file which corresponds to your
Scrabble::Scoringclass. This spec should contain one red test as a starting point (this test can be modified as your get further through the requirements). - Be able to execute your one test using
rakefrom the project root.
| Letter | Value |
|---|---|
| A, E, I, O, U, L, N, R, S, T | 1 |
| D, G | 2 |
| B, C, M, P | 3 |
| F, H, V, W, Y | 4 |
| K | 5 |
| J, X | 8 |
| Q, Z | 10 |
Create a Scrabble::Scoring class with a minimum of 8 specs. The class should have the following class methods:
self.score(word): returns the total score for the given word. The word is input as a string (case insensitive). The chart in the baseline requirements shows the point value for a given letter.- A seven letter word means that a player used all the tiles. Seven letter words receive a 50 point bonus.
self.highest_score_from(array_of_words): returns the word in the array with the highest score. In the case of tie, use these tiebreaking rules:- It’s better to use fewer tiles, in the case of a tie, prefer the word with the fewest letters.
- There is a bonus for words that are seven letters. If the top score is tied between multiple words and one used all seven letters, choose the one with seven letters over the one with fewer tiles.
- If the there are multiple words that are the same score and same length, pick the first one in the supplied list.
These comprehension questions are optional, and do not need to be answered/submitted with the project. They are simply here to help you check for understanding after each wave.
- How did writing tests help you approach writing the scoring logic?
- How did you choose to relate letters to their point value? Why did you choose that way? What other ways could you have related letters to their point value, and what would the advantages and disadvantages to those approaches be?