Makers Day 13

I had a few good learning moments today. To start with, rspec:

def initialize
@locked = true
@entries = Entries.new
end

This is a bad way to inject a class into another class. ‘Entries.new’ is now hard coded into this new class, which means that I can’t ‘double it out’ when I test it. A more appropriate solution would be:

def initialize(entries = Entries.new)
@locked = true
@entries = entries
end

This way, when instantiating my new class in my test, I can pass a double in as the initial argument, thus allowing me to isolate my test.

More on rspec:

it “allows the user to add an entry if the diary is unlocked” do
entries = double(:entries)
diary = Diary.new
diary.unlock
text = “Sample text”
expect(entries).to receive(:add_entry).with(text)
diary.add_entry(text)
end

Here, I am testing the ‘add_entry’ method for ‘diary’ class, and I’m expecting that ‘entries’ in this method will receive a certain method with an argument — add_entries with (text). Essentially, this method isn’t returning anything, but it is actioning something, so I am just checking that when the method is called, this action is carried out.

Another similar example:

it “allows the user to get the diary entries from an unlocked diary” do
subject.unlock
entries = double(:entries)
text = “Sample text”
allow(entries).to receive(:get_entries).and_return([])
expect(subject.get_entries).to eq([])
end

Here, my method is actually supposed to return ‘something’, perhaps for the user to view. Therefore I’m testing that this ‘something’ is actually what is being returned by the method.

The afternoon was a struggle — building our first web app ‘Battle’. I was chuffed at the end though the the basics were working and I could talk it through coherently…. something like:

1. User types in this URL
2. That particular URL responds to a GET request, so opens up
3. The code for the URL directs the request to a ‘view’ file, which has all the HTML script typed in it, which is rendered and displayed to the user
4. The user can then interact with this new display
5. In our example there was a form to fill in with some names
6. The user fills in this form and clicks ‘Submit’
7. This ‘Submit’ then ‘actions’ whatever the form is coded to do. In this case, it is actioned to make a POST request to another route (URL domain on the site)
8. The app ‘hub’ with all the code for what happens for the requests then looks for this route, and whether or not it can receive a POST request.
9. If it can receive a POST request, it will ‘action’ any information provided by e.g. storing the names from the forms as variables (params).
10. It will then call upon the view file for this route, passing the variables into the HTML code in this view file as required.
11. The HTML file is then rendered, including these user-provided variables, and displayed to the user.
12. Rinse and repeat.

I also think I get the point of the Capybara workshop… it so that when you write tests for your website or app, you can dictate what buttons etc. get clicked where and when! Another penny-drop moment.