Request, Response & Capybara

Date: 3rd October 2022, 1:53 pm

One month into the course and I can now see how Ruby classes, methods and variables can interact with web applications and it is all becoming more visual. The past two weeks, we spent a lot of time learning about servers, clients and HTTP servers. In particular, teaching us how the server and client interact using request and response methods. Developer Server Blog Post ImageThe more I went through the practicals and workshops for this week, the more I realised how similar this was to npm, nodeJS, JavaScript, etc. However, I kept wondering the whole time, "How can you test a web application", considering I have never actually done that.

Developer Capybara Testing Blog Post ImageWe first created the Gemfile, using bundler, where we could place all our dependencies. For this week's challenges, we needed Sinatra as a DSL, Capybara (yes, the big friendly rodent) for test automation, Rspec as the testing tool and Simplecov which is a code coverage analysis tool. Once the Gemfile has all the necessary dependencies, you can run bundle in the terminal to install the dependencies and it will create the Gemfile.lock. 

Initialising Rspec (Relish is a fantastic resource) was a little different, in that we had to set up a testing environment first in the spec_helper file. Then identify the ruby controller file (app.rb) and require the testing dependencies. Now we are almost ready to write the first feature test.

Using Capybara is very handy and a lot simpler than it looked initially. The way I see it is typing out the actions that you would normally perform on a web application. As an example, I created an RPSLS game. So as a feature test I would 

Developer Testing Blog Post Image```

'visit '/' 

fill_in(:name), with: 'Fred 

click_button 'Submit'

expect(page).to have_content('Fred')


In short, this feature test is checking that the user can visit the home page, fills their name in the input block provided, and when they click submit, the page will display their name.

Planning Blog Post ImageThis method of feature testing will test the get/post routes, the variable values and whether the content is being displayed on the web application. I am sure that there are a whole number of other elements that can be tested, but this is currently where I am. Of course, we still need the unit tests all well. 

Using Capybara for my feature tests helps me plan out the webpage and how the user can interact with it by typing out, step by step, what the user must do to achieve their goal, whilst also testing the outcome. 

RPSLS Game Blog Post ImageThe method that I followed was to create a feature test, type the code to pass the test, write the unit test and create the necessary classes and methods to pass those tests, and repeat. I am way too new to this to say whether this is the best way or not, but I am sure that I will only improve from here. This method of TDD helped me through the challenges for the past two weeks which I have included with GitHub links. Due to time constraints throughout the week, some are still "Under Construction", but I will keep working on them. Battle - A 2 player game that you could play either against another player or against "The Machine"; RPS - Started off as the original Rock, Paper, Scissors game, that then later included Lizard and Spock; Bookmark Manager - Create a list of easy to access website links, Chitter - Which is simply a Twitter clone.

Although these challenges have kept me very busy and running into blockers has been time-consuming, they have been extremely fun. I continue to see the value of using a TDD method whilst I code. It minimises the amount of time I would maybe have to spend debugging hundreds of lines of code.

Please use the links provided if you are at all interested in getting a better understanding of the dependencies and methods discussed. Looking forward to the next week.