Accidental Technologist

Musings about Entrepreneurship, Technology and Software Development

  • Home
  • About
  • Still River Software
  • Privacy Policy

Powered by Genesis

How to Fix Rails Flash Rendering When Using Hotwire

May 14, 2021 by admin Leave a Comment

Tweet

I added Hotwire to a Ruby on Rails application I’ve been working on and discovered some issues when rendering flash messages. Yesterday I wrote about problems related to CORS error using OmniAuth.  Today’s is not as exciting but still as annoying.

Problem

I was in the process of testing some validation changes I implemented and realized errors were not being displayed. I went through the typical debug scenarios and found that errors were being returned but just not displayed.

The code consists of just trying to create a user:

def create
  @user = User.new(user_params)
  if @user.save
    redirect_to root_path, notice: “User created successfully“
  else
    render :new
  end
end

When creating a user, the new form rendered but errors were not displayed.

Solution

The reason the messages were not being displayed is because of Turbo and Rails UJS conflicting. Solving the problem can be done in one of two ways.

1. It appears Turbo expects form submissions to redirect to a new location. When there is an error, we are staying on the same page. Adding status: :unprocessable_entity to the render fixes the problem.

def create
  @user = User.new(user_params)
  if @user.save
    redirect_to root_path, notice: “User created successfully“
  else
    render :new, status: :unprocessable_entity 
  end
end

2. A similar solution from yesterday’s post also works. Adding

data: { turbo: false }

The form declaration disables turbo and lets Rails UJS handle as desired.

I hope future versions of Turbo handle this better.

Share this:

  • LinkedIn
  • Twitter
  • Facebook
  • Email
  • More
  • Pinterest
  • Tumblr
  • Pocket
  • Reddit

Filed Under: Hotwire, Ruby on Rails Tagged With: Hotwire, Ruby on Rails, Turbo

Hotwire Fix for CORS Error when using Omniauth

May 13, 2021 by Rob Bazinet Leave a Comment

Tweet

I’ve been working on a small side project lately and having some fun trying some new Ruby on Rails features.

The application allows a user to authenticate using their Twitter account. I’m using the omniauth-twitter gem to implement the Twitter strategy with OmniAuth. It works great; the user is redirected to Twitter to enter their Twitter username and password then sent back to the site with a token for the user’s account.

The Problem

Everything was working great until I implement some of the HTML over the wire goodness of Hotwire.

I have a couple of areas on the site that rely on a Sidekiq and update a page when the job is complete. A perfect use case for Hotwire. The job processed, changes broadcast, and pages updated when the model changed. It worked as planned!

I deployed the update using Hotwire, tested and everything was working as I wanted. Deciding to authenticate a different Twitter account, no longer was I sent to the Twitter page to enter my credentials. No error on the page; it just did no redirect.

I looked for any errors in the Rails log. I could see the request initiated but it seemed to drop out of sight with nothing additional logged and no errors.

Maybe it’s a browser-specific issue. I usually use Firefox so I tried Chrome and Safari with the same results. Digging a bit deeper I decided to look at the Network tab in the browser to see if the request was giving an error and I found nothing. The request wasn’t going out to Twitter.

Inspecting the console in Firefox revealed this ugly message.

Access to fetch at 'https://api.twitter.com/oauth/authenticate?oauth_token=<my secret token>' (redirected from 'http://127.0.0.1:3000/auth/twitter') from origin 'http://127.0.0.1:3000' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

I started to search around for the error, and many solutions had me trying the rack-cors gem and other methods to satisfy what needed to be done. Nothing worked. I spent a couple of hours going down this path to no avail. The error is deceiving and not indicative of the real problem.

Debugging

I had done many updates since the last time I knew this worked, including gem and NPM package updates. After removing and testing each update, the message still appeared.

I determined which code was updated since the feature recently worked. I evaluated and ranked each change by how much I thought it could cause the problem. The only change that was a bit of a black box to me was the addition of Hotwire to the mix. I removed the Hotwire-rails gem and removed all the code related to Hotwire and, moved back to Turbolinks. Magically it all worked again.

Adding Hotwire caused this problem.

A Solution

Being new to Hotwire I wasn’t sure where to start. I started with what any good developer does…a Google search.

I came across some posts on the Hotwire forums and on the Devise Github issues list that provided a solution that worked. One, in particular, gave this solution:

It seems like adding

:data => {turbo: "false"}

and making my link a button seems to make it work as per: Devise github login not working after Turbo enabled. · Issue #45 · hotwired/turbo · GitHub. I now have a different error, but that it something different. So I suppose this is solved for now.

The original button I used to connect with Twitter, looked like this:

button_to "Connect a Twitter account", "/auth/twitter", method: :post, class: "btn btn-primary"

After the suggestion above, it now looks like this:

button_to "Connect a Twitter account", "/auth/twitter", method: :post, data: {turbo: "false"}, class: "btn btn-primary"

After adding the code to the button, it works as it did before. Simply don’t use Turbo for this type of request.

The Turbo docs do discuss disabling Turbo on specific links. The error I received did not do a good job of pointing me in the right direction and I spent some time going down the wrong path. I hope someone else can save some time if they have a similar problem.

Conclusion

Solving this problem was time-consuming, but I learned a bunch. Hotwire is in beta at this time. I’m sure things will improve, and maybe we don’t have to solve problems in this way in the future.

A lesson I learned is the need for some better end-to-end tests for this project. I thought since it was going to Twitter and back, it wasn’t necessary. I was wrong.

Share this:

  • LinkedIn
  • Twitter
  • Facebook
  • Email
  • More
  • Pinterest
  • Tumblr
  • Pocket
  • Reddit

Filed Under: Hotwire, Ruby on Rails Tagged With: CORS, Hotwire, Omniauth

RailsConf 2021 and the Future of Conferences

April 20, 2021 by admin Leave a Comment

Tweet

Railsconf 2021 flag

I attended RailsConf this year, as I did last year. Due to COVID-19 these events were virtual-only. Unlike last year, this year’s event included a live component for keynote speakers as well as a large number of Discord rooms so that attendees could live the hallway track as best a virtual even could provide.

Organizers reported attendees took part from 61 countries.

CleanShot 2021 04 20 at 16 14

There were 5 keynotes, 60 talks (not including attendee lightening talks) and 11 workshops over 4 days. The talks were prerecorded so they could be viewed at anytime. This is a nice feature; as someone who has attended the in-person RailsConf in the past, it’s always hard to decide what talks to attend and sustain the energy to watch one during every time slot. 

The keynotes and workshops were live and took place in the afternoon and late morning, respectively. This year live lightning talks, game show, sponsor talks and speaker Q&A were added and made the experience feel as close to in-person as possible.

The 60 session talks will be up on the Ruby Central Youtube channel with a month after the event. Lots of really great talks and tons to learn.

This format worked great but I do miss the in-person events when you can see old friends face-to-face, have good conversations and enjoy group dinners out. I hope next year there is an in-person component of RailsConf. It does appear RubyConf will offer both in-person and virtual attendance. This gives attendees options and likely means more people can attend since some would miss because they couldn’t get away. 

I don’t know the numbers for previous RailsConf, but I would have to think attendance was not close to 61 countries.

We are seeing the future

As bad as COVID-19 was for so many, we may see some positive changes for the future.

Conferences were designed to be in-person, face-to-face meetups, bringing attendees from all over the world to a central location. COVID-19 has shown us there had to be a different way. 

Organizers had embrace a new way of holding events or shutdown. Technologies like Zoom and Mux proved online video is a solid technology, capable of the demands of many users.

Events than can offer both an in-person and virtual experience, stand to gain the most. This opens up opportunities for both organizers and attendees. People who would not be able to attend a particular conference in-person would now not miss the event because they can watch in the comfort of their home or office. Organizers that had to limit attendance can now open up and allow so many more to take in the event. Win..win.

I’m looking forward to attend more conferences in 2021 than ever before. I will attend some in-person but will attend others virtually. The RailsConf organizers and folks at Ruby Central should be applauded for a great job.

Share this:

  • LinkedIn
  • Twitter
  • Facebook
  • Email
  • More
  • Pinterest
  • Tumblr
  • Pocket
  • Reddit

Filed Under: Ruby on Rails Tagged With: railsconf, rubyconf

Overcoming the Mimemagic Fiasco

March 26, 2021 by Rob Bazinet Leave a Comment

Tweet

I’m sure if you are a Ruby on Rails developer, you have heard about the fiasco that is Mimemagic.

It seems a component used in the Mimemagic gem was under a GPL license which was different than Mimemagic but because of how these licenses work, trickles down to users of Mimemagic. In this case the Ruby on Rails gem. If you’re interested in some of the background, the Ruby on Rails issue, Dependency on mimemagic 0.3.x no longer valid #41750, can fill you in.

The gem was yanked from Rubygems and because of this, the gem could no longer be installed so builds broke everywhere. Users received the message:

Your bundle is locked to mimemagic (0.3.5), but that version could not be found
in any of the sources listed in your Gemfile. If you haven’t changed sources,
that means the author of mimemagic (0.3.5) has removed it. You’ll need to update
your bundle to a version other than mimemagic (0.3.5) that hasn’t been removed
in order to install.

I have several clients needing a way to resolve this problem.

I came up with a couple different options.

Option 1 – Remove Dependency

After a bit of research I discovered that Mimemgic was used by the Marcel gem which is required by ActiveStorage. If the application did not use ActiveStorage then removing the dependency would solve the problem. If you use ActiveStorage, this is not an option.

Implementing this is pretty straightforward. Opening up your config/application.rb, you should see where Rails is required:

require "rails/all"

Instead of requiring all, just require what you need and remove the ActiveStorage dependency. This is what requiring rails/all includes:

active_record/railtie
active_storage/engine
action_controller/railtie
action_view/railtie
action_mailer/railtie
active_job/railtie
action_cable/engine
action_mailbox/engine
action_text/engine
rails/test_unit/railtie
sprockets/railtie

Just remove the second line and require each of these individually and you will be all set.

Option 2 – Change how the gem is included

Since the Mimemagic gem is open source and the code is in a git repo, we can identify the commit created when version 0.3.5 of the gem was released. Some commits that should solve the problem:

  • 0.3.3  https://github.com/mimemagicrb/mimemagic/commit/d5ebc0cd846dcc68142622c76ad71d021768b7c2
  • 0.3.4  https://github.com/mimemagicrb/mimemagic/commit/64b60d125432bde900fa4d9f77fb6f057a0c325a
  • 0.3.5  https://github.com/mimemagicrb/mimemagic/commit/01f92d86d15d85cfd0f20dabd025dcbd36a8a60f

My projects have been using v0.3.5, I found the commit and added this to my Gemfile:

gem 'mimemagic', '0.3.5', git: 'https://github.com/mimemagicrb/mimemagic', ref: '01f92d8'

This is a short-term fix. I expect once the Rails team resolves the dependency, new versions of Rails will be released.

Share this:

  • LinkedIn
  • Twitter
  • Facebook
  • Email
  • More
  • Pinterest
  • Tumblr
  • Pocket
  • Reddit

Filed Under: Ruby on Rails Tagged With: Ruby on Rails, rubygem

frozen_string_literal: the not so magical comment

March 16, 2021 by Rob Bazinet Leave a Comment

Tweet

I have been working on a project over the past year for a client with a large Ruby on Rails application. The project has allowed me to learn more about how large Rails applications are developed and managed in the real-world. I’ve picked up some real gems to help scale Rails applications which I’ve used in some of the smaller applications I maintain.

One of the gems I learned about was the use of this magic comment:

# frozen_string_literal: true

This comment was added to every Ruby file in this company’s application, which included several microservices along with a large main application. The files numbered over 1,000.

I read up on the use of this magic comment use in other projects and the results seen. One in particular was Sidekiq from Mike Perham. Mike documented his use of the magic comment and how it improved his use and helped cleanup his code.

Ruby 2.3 introduced a very nice option: each Ruby file can opt into Strings as immutable, meaning all Strings within that file will automatically freeze, with a simple magic comment at the top of the file.

Mike includes some benchmarks that show improved memory footprint for Sidekiq. This was enough for me.

I had one relatively small application that had an API component I was optimizing (Rails 5.2.x and Ruby 2.6.6). I thought about the use of the magic comment and decided to give it a try. I added it to every Ruby file in the project and was included as part of the weekly deploy.

The deploy was done after hours one evening and I was ready to witness the magic.

Unfortunately, this magic did not happen. I noticed right away the response times of API calls were slower, not faster. Maybe I was seeing the effects of cold cache calls and things would improve overnight.

The next morning in fired up Skylight to check the response times from the API. To my surprise, the response times did not improve. Since the only change in this deploy was the use of magic comments, I decided to rollback the changes. This application runs on Heroku, rolling back with really easy and does not require reverting the code back and redeploying.

The result was noticed instantly:

IMG 1186

Response times drastically improved as you can see from the above graph.

At this point, I don’t have any reason to believe it’s not the magic comment that caused these longer response times.

During my brief research about the comment’s use, thinking there was more to using it than simply using it everywhere, I ran across a thread from the Ruby lang issue list. The threads title, Reconsider impact of frozen_string_literal on dynamic strings, I found interesting. Maybe this is a clue and dynamic strings being frozen in my application is part of the problem.

It sounds like there is a benefit to use this feature but not everywhere, the exact result I saw in performance graphs.

I am still exploring when to use the magic comment and when it shouldn’t be used. If you are using this throughout your applications it might be worth measuring with and without their use. Any others have more information to share, please reach out.

Share this:

  • LinkedIn
  • Twitter
  • Facebook
  • Email
  • More
  • Pinterest
  • Tumblr
  • Pocket
  • Reddit

Filed Under: Ruby on Rails Tagged With: Ruby, Ruby on Rails

11 Ruby on Rails Podcasts Worth Your Time

February 18, 2020 by Rob Bazinet Leave a Comment

Tweet

Ruby on Rails

There is great value in the Ruby on Rails podcasts and screencasts we have available today. Some podcasts have gone away while others have appeared, and others have changed hosts. The title is a bit deceiving, I’m including some screencasts too.

I wrote up a list of Rails learning resources last week, which included some screencasts. I list those here to keep the resource consistent for folks finding this in the future.

Podcasts

I have far too many podcasts in the Overcast app on my iPhone, but these always get listened to first.

Remote Ruby – three developers, chat about Ruby on Rails, what they’re up to, and the community at large. Occasional guests.

Ruby on Rails Podcast – this podcast has been around a long time and has seen a few hosts. Episodes consist mainly of interviews with people in the industry or who use Rails for their jobs. I do really like the guests and topics, many are the cutting edge of what we are being exposed to in work today.

Ruby Rogues – a long time show featuring a panel of known people from the Rails community who discuss various topics with guests. Episodes are mainly a single timely topic the panel and guest discuss. Approaching 500 episodes.

Rails with Jason – interview-style show with Jason Sweet. Jason has some great guests on his show. If you can listen to only one, I’d try this one. If you can’t get enough of Jason, he has written some great articles.

Maintainable – hosted by Robby Russell, long-time Rails developer and founder of Planet Argon, a Rails development agency. From the Maintainable site:

On Maintainable, we speak with seasoned practitioners who have worked past the problems often associated with technical debt and legacy code. In each episode, our guests will share stories and outline tangible, real-world approaches to software challenges

Running in Production – a podcast about how folks are running various frameworks in a production environment and what it takes to do so. Not strictly talking about Rails, but there are a handful of episodes specifically dealing with challenges of running Rails in production.

The Bike Shed – discussion podcast, with two people from Thoughtbot. Much of the discussion encompasses issues the hosts face while working at the company. The episodes aren’t strictly Rails but cover topics many of us face in our day-to-day development work.

Screencasts

Drifting Ruby – created by Dave Kimura, also a long-time Rails developer. Dave is currently up to 227 episodes with episodes running from ~10 min to ~30 min. You might think these screencasts are probably like those from Go Rails, hardly. I think they complement each other very well. Even for topics, they are the same. I find the approaches very different. There are also free episodes, while others require a small monthly fee.

Go Rails – created by Chris Oliver, who is a great contributor to the community. At the time of this writing, Chris is up to 330 videos of varying lengths (~5 min to ~30 min) covering a full breadth of topics, including everything from Rails concepts to the inevitable problem you’ll face when creating Rails applications. There is also a forum that accompanies the videos were you can ask questions or answer some if you so choose. There are some free videos and a Pro plan you can pay to get the rest of the videos for a reasonable monthly fee. It’s a bargain for sure.

RubyTapas – created by Avdi Grimm, a long-time member of the Ruby community. From the RubyTapas website:

RubyTapas is for the busy Ruby or Rails developer who is ready to reach the next level of code mastery. Short, focused screencasts twice a week will introduce you to a wide variety of intermediate to advanced Ruby concepts and techniques, Object-Oriented design principles, testing practices, refactoring skills, and much more.

RailsCasts – created by Ryan Bates, these short screencasts were the original for the Ruby community focusing on Ruby on Rails. Ryan stepped away from making these a while ago, but many are still relevant today and free.

There’s so much great content in these resources. Whether you like to listen to podcasts or prefer to watch people code in a screencast, there’s plenty to learn. If you find other Ruby and Rails related podcasts, I’d love to know about them.

Share this:

  • LinkedIn
  • Twitter
  • Facebook
  • Email
  • More
  • Pinterest
  • Tumblr
  • Pocket
  • Reddit

Filed Under: Ruby on Rails Tagged With: podcast, Ruby on Rails

10 Ruby on Rails Learning Resources for 2020

February 6, 2020 by Rob Bazinet Leave a Comment

Tweet

Even though Ruby on Rails has been around since 2004 as an open source project, I still get asked the best ways to learn the framework today.

It’s a fair question and answers do change as the Ruby on Rails landscape has evolved.

Beginner Level

You have little to no Ruby on Rails knowledge and are looking for resources to get you started out right.

  1. The Ruby on Rails Tutorial by Michael Hartl – now in it’s 6th edition and keeping up with Rails 6. This book and video options (20 hours) help many Rails developers get started. It’s written my Michael Hartl and comes in at 883 pages. It is a well-written tutorial.
  2. Ruby on Rails Guides – when talking about getting information from the source, this is the one to use. Each section contains the documentation on all the major parts of the Ruby on Rails framework broken up by function. A nice feature is users can select the version they are using, starting with the latest as of this writing, 6.0.2.1 all the way back to 2.3.
  3. Agile Web Development with Rails 6 – the Rails 6 version of the book which has gotten many Rails developers started, including myself. The Pragmatic Bookshelf offers a version back to Rails 4 so make sure you reference the correct version. This version will help with coming up to speed on the new Action Mailbox and Action Text. It offers source code for the project, which is a nice eCommerce application with practical value.
  4. Agile Web Development with Rails 5.1 – this version of the book is, you guessed it, targeting Rails 5.1. It contains the latest updates for 5.1 and offers source code for the project, which is a nice eCommerce application with practical value.

Intermediate Level

You’ve built a couple applications, know the beginner material and have a couple years of Rails experience. You are ready to move on to hone your skills.

One of the-best ways to learn, for me and I’m sure others, is by watching screencasts. The next two resources are they best out there.

  1. Go Rails Screencasts – created by Chris Oliver who is a great contributor to the community. At the time of this writing Chris is up to 330 videos of varying length (~5 min to ~30 min) covering a wide breath of topics, including everything from Rails concepts to the inevitable problem you’ll face when creating Rails applications. There is also a forum that accompanies the videos were you can ask questions or answer some if you so choose. There are some free videos and a Pro plan you can pay for to get the rest of the videos for a reasonable monthly fee. It’s a bargain for sure.
  2. Drifting Ruby Screencasts – created by Dave Kimura, also a long-time Rails developer. Dave is currently up to 227 episodes with episodes running from ~10 min to ~30 min. You might think these screencasts are probably like those from Go Rails, hardly. I think they complement each other very well. Even for topics they are the same, I find the approaches very different. There are also free episodes and others are paid for with a small monthly fee.
  3. Modern Front-End Development for Rails – when moving to recent versions of Rails, 5.1+, you have exposure to technologies such as JavaScript with the required tooling. This book takes you there and helps clear up some of the confusion that will certainly arise.

Advanced Level

You feel good about your Ruby on Rails skills and want to press on to even more advanced topics.

  1. Metaprogramming Ruby 2 – if you aren’t sure what metaprogramming is, it’s worth learning about and use it where it makes sense. It’s a technique that’s used in Rails and other Ruby frameworks and applications. It’s powerful. This book is the best resource I’ve found on the subject from just learning it to becoming proficient.
  2. Rails 5 Test Prescriptions – the Rails community is all about Test-Driven Development (TDD) and this book gives great coverage of the subject. It covers RSpec and mintiest. RSpec is probably the most popular testing tool for Rails. Mintiest is the default testing framework.
  3. Docker for Rails Developers – unless you’re living under a rock you have at least heard of Docker. This book is the only source I am aware of that directly helps Rails developers containerize their application. It is a great single source.

If you’re just starting out, a seasoned expert or somewhere in between. I think these are some of the best sources of guidance and knowledge available for our beloved Ruby on Rails.

If you think I forgot something, please leave a comment and let me know.

Share this:

  • LinkedIn
  • Twitter
  • Facebook
  • Email
  • More
  • Pinterest
  • Tumblr
  • Pocket
  • Reddit

Filed Under: Ruby on Rails Tagged With: Ruby on Rails

When You Can’t Check a Checkbox using Capybara

December 5, 2018 by Rob Bazinet Leave a Comment

Tweet

In my last post I documented an issue I was having using Capybara on a client’s Ruby on Rails application with a ReactJS frontend.  I wanted to share another issue I came  across during my feature testing escapades.

The Problem

During my recent feature testing project I had a form which has a checkbox on it. The checkbox had a label with it. Did I mention this is a ReactJS frontend? I’m not sure if this is specific to ReactJS, but I suspect it isn’t. I think other frontend JavaScript frameworks may exhibit the same problem.

The Ruby code for my feature test is dead simple:

check “English”

That’s it. The test should run and when it finds the checkbox with a label of English, the checkbox should be checked. But, it doesn’t work. After many attempts at making this work and more Google searches than I can remember..I ended up at the Capybara mailing list.

The Solution

Thomas Walpole was kind enough to reply with his thoughts on the matter:

99.9% sure your checkbox isn’t actually visible on the screen.

What you’re describing as the “checkbox” is probably an image (probably added via CSS pseudo elements) being shown in place of the actual checkbox input element to ensure the same styling across different browsers.  If the checkbox has a label element correctly attached to it you can use `check(‘whatever’, allow_label_click: true)` – https://www.rubydoc.info/ github/jnicklas/capybara/ Capybara/Node/Actions#check- instance_method –  to tell Capybara to click the label element instead of the hidden checkbox input to toggle state.  If you don’t have an associated label then you’ll need to find whatever element is actually visible on the page and click it instead.

Changing my test to include this for the checkbox, worked perfectly.

check(“English", allow_label_click: true)

I hope someone finds this valuable and will save them some time and hair pulling.

Share this:

  • LinkedIn
  • Twitter
  • Facebook
  • Email
  • More
  • Pinterest
  • Tumblr
  • Pocket
  • Reddit

Filed Under: Ruby on Rails Tagged With: capybara, rspec, Ruby on Rails, tests

Fixing StaleElementReferenceError When Using Capybara

December 4, 2018 by Rob Bazinet Leave a Comment

Tweet

I’ve been spending an extended period of time lately writing Feature specs for a Ruby on Rails project using Capybara. Overall it’s been a fun project to work on but I had run into a few issues along the way. One in particular is the StaleElementReferenceError exception that get thrown when you are trying to find an element on your page that you know is there but Selenium can no longer find.

The error appears to be a timing issue between the page loaded in the browser, it being rendered and Capybara and Selenium trying to find the element. After much trial and error, along with many Google searches, I found no solutions that were reasonable. Even though many people had the same problem.

The solution was pretty simple actually. I added a rescue to my test and simply slept for 1 second and retry the failure. I admit, this seems like a hack but it works and that’s all I really cared about at the time. I see no ill effects from this, no measurable delay.

RSpec.feature "Listings", type: :feature, js: true do
  scenario "can edit common area - step 3" do
    begin
      post_a_space_step_1_with
      click_on 'Next'
      post_a_space_step_2_with
      click_on 'Next'
      click_on 'Edit Common Area'
      expect(page).to have_content "Step 1"
    rescue Selenium::WebDriver::Error::StaleElementReferenceError
      sleep 1
      retry
    end
  end
end

I’m certainly open to a better solution or an explanation as to why this might be bad. Please leave comments. Hopefully I help someone get around this really annoying problem.

Share this:

  • LinkedIn
  • Twitter
  • Facebook
  • Email
  • More
  • Pinterest
  • Tumblr
  • Pocket
  • Reddit

Filed Under: Ruby on Rails Tagged With: capybara, Ruby on Rails, selenium

Ruby on Rails Testing Resources

November 14, 2018 by Rob Bazinet Leave a Comment

Tweet

When taking the plunge into Ruby on Rails it’s really easy to get carried away with learning all about the framework. It’s easy to learn the fundamentals and later realize the Rails community is a community of testers. It’s a strange world when you set out to learn about testing, TDD (test-driven development), BDD (behavior-driven development) and other acronyms and phrases relating to testing Ruby on Rails applications.

I decided to put together a short list of helpful resources to get started. If you have suggestions that would be useful to be added to this list, please add a comment or email me directly and I’ll update this post.

Books

  • Everyday Rails Testing with RSpec – this is a great, hands-on, roll-up your sleeves and get-to-work book. If you want to use RSpec on a daily basis, this book gives great advice on how to use RSpec in your day-to-day routine. It’s kept up-to-date with latest RSpec too.
  • Rails 5 Test Prescriptions – I use this book as a reference I often go to. It’s been updated to from previous versions to now Rails 5 and is a great tool to have on the shelf.
  • Effective Testing with RSpec 3 – if you decide you’d rather start without worrying about all the details around Rails you can start with learning RSpec with plain Ruby and help yourself. I’ve been through this one cover-to-cover and it’s a great tutorial.
  • The Minitest Cookbook – if you decide RSpec isn’t for you, this is probably the ultimate resource for Minitest. Well-written and kept up-to-date.

Podcasts

You can’t really learn testing from a podcast but you can learn how others approach the craft. The first is a podcast dedicated to testing Ruby applications. The rest is a list of a few episodes of podcasts that discussed testing.

  • The Ruby Testing Podcast
  • Ruby Rogues 385: “Ruby/Rails Testing” with Jason Swett
  • Ruby Rogues 269 Testing
  • Full Stack Radio 46: Joe Ferris – Test Driven Rails

I’ve been listening to The Ruby Testing Podcast and picked up some nice tidbits so far.

Training

I love Pluralsight.

  • RSpec the Right Way
  • Test-driven Rails with RSpec, Capybara, and Cucumber

Xavier Shay has long been involved in the Ruby community and well-known for discussions around testing. One of his best blog posts explains his approach to testing.

  • Testing Ruby Applications with RSpec

I’ve taken several courses on Udemy and they are one of my favorite places for training. The prices are low and there are many courses, so you have to do a bit of work to see which course is right for you but well worth the effort.

  • The Complete TDD Course: Master Ruby Development with RSpec
  • Ruby on Rails 5 – BDD, RSpec and Capybara

Share this:

  • LinkedIn
  • Twitter
  • Facebook
  • Email
  • More
  • Pinterest
  • Tumblr
  • Pocket
  • Reddit

Filed Under: Ruby on Rails Tagged With: bdd, minitest, rspec, Ruby on Rails, tdd, unit testing

Next Page »

Recent Posts

  • How to Fix Rails Flash Rendering When Using Hotwire
  • Hotwire Fix for CORS Error when using Omniauth
  • Fix Installation of Ruby using rbenv on macOS Big Sur
  • RailsConf 2021 and the Future of Conferences
  • Fixing Out of Diskspace Errors on Amazon EC2

Categories

Services I Love

HatchBox - Easy Rails Deploys Fathom Analytics
Follow @rbazinet

Rob Bazinet (ruby.social/@rbazinet)
@rbazinet

  • Working to wrap up my current consulting gig by mid-April. I will be looking for the next thing soon. If anyone has… https://t.co/sg3cSV9yqM
    about 12 hours ago
  • I’ve been spending some time using Notion AI lately and it surprisingly good. Since all the rage lately is ChatGPT,… https://t.co/cUXFWIRCVV
    about 3 days ago
  • I think these steps are true for any target audience. https://t.co/0ht6rIzOW3
    about 3 days ago
  • I’ve been enjoying a show from the Magnolia network called The Craftsman. It’s mainly about woodworking but his phi… https://t.co/sWTUBbSsl6
    about 4 days ago
  • I found the resource I was looking for last night that is similar to https://t.co/Pyn0IIjRdP, it is… https://t.co/U7TMe77FMF
    about 4 days ago
  • RSS - Posts
  • RSS - Comments
Find me on Mastodon