minesweeper 0.0.1 → 0.0.2

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA1:
-  metadata.gz: b10193144ceaeb6995ac3a3a4c747953ac4cc346
-  data.tar.gz: 28a61a483e56e28d921f29a8e6b46b47c1783e7b
+  metadata.gz: 52ba8f9bc591a9dbb7df82eb99942ffa2340fb57
+  data.tar.gz: 23bc36c84d3a6b7d6c291410c87db70415c13b39
 SHA512:
-  metadata.gz: 635519e896eba1fe969dcc1c525a39c8a970ed2dcae841c4936a1e05d5e8495f2ae7354adf48db25fb8806e280c7400b62de89bd7200347354625b4c72e33ffe
-  data.tar.gz: 84589c0690f06746c87c49276a9b03aeb59f64c2c787531dbc180e818b9b7b0e935dfcc3be0268d55812a2fb3785536d45e25b61ee531f8c04a5142b9cee5b27
+  metadata.gz: 31822b402b82e4295b1d3ca11b06a34a365d6043fcb44148c2603cd18bd567c4e899a8c39bbe529247a062918a1b470e549d5fabad6cc1c0a09ca6fb6d954518
+  data.tar.gz: ca4477a57293255d7733016212e27bdc3e71be6999780751d121c1a7ab880691909aeb094fc5c830f24fb508f985180e935085512fbc7b794f68b2cf0fed9eb1

data/lib/minesweeper/version.rb

@@ -1,3 +1,3 @@
 module Minesweeper
-  VERSION = "0.0.1"
+  VERSION = "0.0.2"
 end

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: minesweeper
 version: !ruby/object:Gem::Version
-  version: 0.0.1
+  version: 0.0.2
 platform: ruby
 authors:
 - Michael Alexander
@@ -78,7 +78,6 @@ files:
 - Gemfile
 - Guardfile
 - LICENSE.txt
-- README.md
 - Rakefile
 - lib/.DS_Store
 - lib/minesweeper.rb

data/README.md

@@ -1,55 +0,0 @@
-Minesweeper TDD Solution
-========================
-
-If you got even most of this project done, you can consider yourself *far* beyond a beginner in Ruby. You're TDDing like the pros, and learning to decompose your methods. Most of all, what you should have learned from this is that smaller and more isolated methods are easier to test, and it's much easier to set up an example than to try to test by absolute logical necessity.
-
-##Points of Interest
-
-- the game loop itself is hard to test beyond expecting messages to be sent to certain objects
-    + make sure to stub out victory conditions so your test doesn't get caught in an infinite loop
-- the board is where the meat of the logic is, and that's where unit testing is most effective
-- to test methods like counting adjacent mines, cheat
-    + use a `before` clause to set mines exactly where you want them
-    + then run your `#num_adjacent_mines` method
-- testing automated mine clearing is hard. don't look for the perfect algorithm here
-    + instead, see if a mine with zero others around it also clears off the 8 mines surrounding it
-- remember that the `equal` method and the `eq` method in Rspec are not the same
-    + if something `equal`s `true`, then it literally IS that object
-    + if it `eq`s `true`, that's normal Ruby Boolean truthiness
-    + `equal` is VERY useful to make sure boolean methods actually work!
--_Bonus:_ when working with 2D arrays, remember you can always use the `#flatten` method to get at the elements inside.
-    - this comes in really handy when you want to compare two 2D arrays for equality or set all their elements equal
-    - `@board.grid.flatten.each {|s| s.mine = false }` is a one-liner to remove every mine from the board, as another example
-
-
-## A bonus
-
-You can iteratively generate expectations, even stack them. It's not often the right way to go, but every once in a while it's perfect.
-
- See here:
-
-```code-rspec
-
-context 'if the space has zero mines nearby' do
-# ...other stuff
-
-    it 'should uncover all adjacent mines' do
-
-      subject.mark_clear(3,3)
-
-      # whoa! you can iterate expectations!
-      # this way, the test fails if any one of these 
-      # *NINE* expect clauses fail
-      # which is to say, if any adjacent square remains hidden
-
-      2.upto(4) do |x|
-        2.upto(4) do |y|
-          expect(subject[x][y].visible).to equal true
-        end
-      end
-
-    end
-end
-```
-
-*NOTE: This solution repo is copyrighted material for your private use only and not to be shared outside of Viking Code School.*