Skip to content

Conversation

@m-pitera
Copy link
Owner

Implemented feedback into the program; the user will now get the correct feedback after their guess.

m-pitera added 11 commits July 18, 2018 16:18
weird bug that the game takes inupt without actually taking it when guess has all the correct nums, but in the wrong order
Pin logic now implemented. The previous issue was that using the until loop I was treating as a while or something weird.
the tests are mainly regarding dif cases that compare_to_guess will output correctly

def guesses_left?(guesses_left)
!guesses_left.zero?
guesses_left != 0
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

guesses_left.positive?

def again(user, code)
GameStatus.game_over?(user.guesses_left)
code.compare_to_guess(user.take_input)
again(user, code)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

again isn't very descriptive. Maybe try_again?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Input feedback?

@@ -1,8 +1,11 @@
require './output'
require 'pry'
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't require pry in PRs

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Er I mean, don't require pry after you're done, get rid of it.

Trick: require 'pry'; binding.pry is a one liner to initiate pry w/o requiring it at the top of the file so you don't forget to remove it

red_pin = feedback.count('red')
white_pin = feedback.count('white')

return [red_pin, white_pin]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Returns aren't really needed here

end
end

# not sure if i should be testing this?
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If it's public, it should be tested

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's not, it's a private method that is called in a public method that is tested below it. So it's technically already being tested?, but i'm not sure whether I should test is as well for more specific-ness?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If it's private, it can't be tested. You can test the public method thoroughly

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or extract it out into another file and then test it

Copy link
Owner Author

@m-pitera m-pitera Jul 25, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right I can't even access it because it's private . . . facepalm

That makes sense, I think that I'll just end up removing it as it's really only testing if this method can count correctly x_x

expect(code.compare_to_guess(guess_s)).to eq [0, 4]
expect(code.compare_to_guess(guess_s)).to_eq [0, 4]
end
xit '4 red and 0 white expected' do
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are these supposed to still be pending? ...Also, I tend to see to eq(THING) more than that way

forgot to revise some of the tests
m-pitera added 2 commits July 25, 2018 14:16
this method was private and didn't provide much behaviour to test
code = SecretCode.new
code.code = [1, 1, 2, 2]
it '2 red and 2 white expected' do
secret_code.code = [1, 1, 2, 2]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

spacing nitpicks => new lines between test cases,


# am I just testing random cases at this point? is this ok?
describe '#compare_to_guess' do
# am I just testing random cases at this point? is this ok?
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe. Maybe hone down the test cases the test the basic core functionality. Are some of them basically testing the same arithmetic and function multiple times?

feedback = Array.new(4) {'red'}
count_pins(feedback)
# expect(red_pin).to_eq 4 && white_pin.to_eq 0
expect(count_pins(feedback)).to_eq [4, 0]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are good test cases...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants