This week I continued to focus on using pry and IRB to break into my rails code. By the end of it all I got the hang of how to conduct an effective investigation of your code, and the different (sometimes subtle) ways you can take advantage of IRB and PRY to see what's happening. I learned a bit more about the placement of my binding.pry, and as I got practice with loops in my Rails tutorial, I was able to play more with the timing of things in terms of when my pry would be activated in my code and what it would show.
I also followed a video introducing me to RSPEC and followed along with the code and wrote two passing tests:
require 'spec_helper'
describe Book do
# before i run the test, I'm making this @book veriable
before :each do
# making a new book with a title author and category
@book = Book.new "title", "author", "category"
end
describe "#new" do
it "returns a new book object" do
expect(@book).to be_a(Book)
end
it " throws an argument error when given fewer than 3 parameters" do
lambda { Book.new "title","Author" }.should raise_exception ArgumentError
end
end
end
And in TERMINAL:
Finished in 0.00769 seconds (files took 0.30765 seconds to load)
2 examples, 0 failures
I also listened to this podcast, Test Driven Development podcast by puppet and got a broader view of the field. They advise essentially the red, green, red light approach- you build a test that breaks your code, fix your code to make it pass the test, then refactor both to optimize them. I also learned a great tip about building your code according to business requirements, rather than behavior (which are too subtly different things) because then if your business requirements change you are one less degree-away from the proper "skeleton" of behavior you want to maintain despite the changes. Very interesting stuff, can't wait to start writing tests in rspec.
Another thing I read about as I researched testing, is the Gherkin method, which I actually heard about in regards to writing specs. That is, there are some ways to write up user requirements that are very conducive to writing unit tests. There are ways people can arrange information about what they WANT a program to do, such that a developer will have no problem translating that into some kind of testing framework. I want to learn more about that and will jump right into it in my spec writing tutorial.
Made a summing thingy and checked it with pry, to practice debugging number thingys:
require 'pry'
value = 0
continue = true
while continue == true do
puts "please input a value to sum"
new_value = gets.chomp.to_i
value = value + new_value
puts "would you like to input another value"
input = gets.chomp
binding.pry
if input == "f"
continue == false
puts "the sum of your values is #{value}"
end
end
PRY:
44: new_value = gets.chomp.to_i
45: value = value + new_value
46:
47: puts "would you like to input another value"
48: input = gets.chomp
=> 49: binding.pry
50: if input == "f"
51: continue == false
52: puts "the sum of your values is #{value}"
53: end
54: end
[1] pry(main)> value
=> 16
[2] pry(main)> input
=> "y"
[3] pry(main)>
made thing that requests that two conditions be fulfilled before the loop will stop. so this is checking for multiple conditionals, and then I practiced debugging something like this, with multiple parts, and learned a thing or two…
tax_due = true
reg_due = true
while (tax_due || reg_due) do
if tax_due
puts "please pay taxes (y/n)"
payment = gets.chomp
if payment == "y"
tax_due = false
puts "thank you for payment"
end
else
puts "please pay registration (y/n)"
payment = gets.chomp
if payment == "y"
reg_due = false
puts "ok you're all squared away"
end
end
end
And the PRY... which actually, I finally understood how pry can help you investigate what's happening. I sucessfully inquired about the status of these variables and saw that tax_due changed to false from true after I'd payed it. Very cool that pry lets you follow along with that.
63:
64: while (tax_due || reg_due) do
65: if tax_due
66: puts "please pay taxes (y/n)"
67: payment = gets.chomp
=> 68: binding.pry
69: if payment == "y"
70: tax_due = false
71: puts "thank you for payment"
72: end
73: else
[1] pry(main)> payment
=> "y"
[2] pry(main)> tax_due
=> true
[3] pry(main)> exit
thank you for payment
please pay registration (y/n)
y
From: /Users/lesliewilson/marlboro_rails/sales-tracking/code.rb @ line 76 :
71: puts "thank you for payment"
72: end
73: else
74: puts "please pay registration (y/n)"
75: payment = gets.chomp
=> 76: binding.pry
77: if payment == "y"
78: reg_due = false
79: puts "ok you're all squared away"
80:
81: end
[1] pry(main)> reg_due
=> true
[2] pry(main)> tax_due
=> false
[3] pry(main)> payment
=> "y"
[4] pry(main)>
one thing I did learn about pry this time around, is that i didin't need two binding.pry's (one after the else, one after the if) because pry will only run one at a time anyway. i could have just put a single binding at the end and been fine. interesting!!
played with applying methods to nil, breaking into it with IRB
print "provide a character"
character = gets.chomp
if "aeiou".index(character)
puts "its a vowel"
else
puts "its not a vowel"
end
and using IRB:
irb(main):001:0> "aeiou".index('b').nil?
=> true
irb(main):002:0>
used this .nil? method to make something that verifies a user actually entered information in a specific way:
print "do you want to continue(y/n)"
character = gets.chomp
if "yn".index(character).nil?
puts "please specify"
end
and running it looks like:
do you want to continue(y/n)u
please specify
so right there I typed "u" and the program caught it.
so below I basically tried to take everything I've learned about pry, about nil values, and make conditionals with a few different sections, and check it with pry:
require 'pry'
puts "provide a character, if you hit y we will add numbers together, no, we will scold you, and anything other than that, you're done with the program"
character = gets.chomp
if character == 'y'
puts "ok we're going to add two numbers for you"
print "whats the first number?"
number_1 = gets.chomp
binding.pry
print "ok! whats the second number"
number_2 = gets.chomp
puts "the sum in #{number_1.to_i + number_2.to_i}"
elsif character == 'n'
puts "you put a different number in"
else
puts "ok you're done with this"
end
and the PRY:
107: character = gets.chomp
108: if character == 'y'
109: puts "ok we're going to add two numbers for you"
110: print "whats the first number?"
111: number_1 = gets.chomp
=> 112: binding.pry
113: print "ok! whats the second number"
114: number_2 = gets.chomp
115: puts "the sum in #{number_1.to_i + number_2.to_i}"
116: elsif character == 'n'
117: puts "you put a different number in"
[1] pry(main)> number_1
=> "5"
[2] pry(main)> character
=> "y"
[3] pry(main)> number_2
=> nil
[4] pry(main)> exit
ok! whats the second number6
the sum in 11
added a while loop to the beginning of it to make it continuously ask for a different input if you don't put in "y" or "n"
while character != 'y' && character != 'n'
puts "please specify 'y' or 'n'"
character = gets.chomp
end
and the output looks like:
provide a character, if you hit y we will add numbers together, no, we will scold you, and anything other than that, you're done with the program
u
please specify 'y' or 'n'
i
please specify 'y' or 'n'
i
please specify 'y' or 'n'
please specify 'y' or 'n