5/18/2023 0 Comments Rspec timecop![]() ![]() Phew, lots of crazy intermittent failing tests, but we have them fixed now. do |username|Įxpect(page).to have_content("Come back soon!") The solution is to make an expectation for what the page should show, that way we know the redirection is finished before we continue with the next session. It was redirecting, and the redirected URL was hitting as the student, not the teacher.Ī temptation is to put a sleep(5) here, which fixes the bug, but we can do better. It looked like the teacher had the wrong data setup, but only sometimes.įinally, we realized that the click\_link "Exit Chat" wasn’t finishing before the loop continued. Unfortunately, this gave another NoMethodError that was harder to track down. At the end of the test, we had something like this: do |username| We had an in-browser test which used Capybara to switch between multiple sessions, so it could simulate two users entering a chat room and interacting. #4 Use expectations to avoid rogue requestsĪ final rogue request was a doozy. It also helps us avoid leaking data about which User IDs are actual users. Our code will happily move along and the problem is avoided. Render :json => it returns “unavailable” when the user doesn’t exist. I changed the code slightly: def = User.find_by_id(params) || User.new(online_status: "unavailable") The test finishes, but the request hits after User X has been deleted from the database, causing the next test to fail with an exception. In one test, it makes a request for the online status of User X. As an intermittent test failure, I suspected rogue requests. Render :json => error we were getting was a NoMethodError on online\_status, which hints that our User isn’t there. It would hit this action in a controller: def = User.find_by_id(params) We had some javascript that checks if another user is online. These requests can then hit during another test without the data you expected. If you’re testing in the browser (we’re using Capybara with Firefox) you can hit issues where there are still requests floating around after a test has finished. When we get the tests all passing again, we’ll work on a cleaner solution. # Unsetting them ensures we get the correct data in every test run. # Navigator caches the category IDs, but they are different between tests. In the interest of getting the tests passing, I added an after to clear out the cached variables. The class variable gets set once, but the database is cleared out between test cases, and the Category won’t be the same anymore. Tests were failing due to categories not being associated correctly with other objects. def ||= Category.find_by(name: "Special Category").id While these are in the database, they aren’t modified on the server so we had a model that caches some of the IDs as class variables. In an RSpec before(:each) we create a few Category records. This one is a bit harder to describe without showing pages of code, but I’ll try. ![]() I’d rather be more precise, but this is a huge test suite so we’ll start by being overzealous and refactor after we have passing tests. I went a step further and put it in my spec_helper.rb to know it will always get reset. Instead of this, I switched to an after(:each). ![]() Sure, but only in these tests which is why we were still seeing intermittent failure. Someone knew we had some test spillage and figured that if we reset Timecop at the start of the test, we’ll be fine. I realized there was a problem when I found this in an RSpec before(:each): before(:each) do ![]() We’re using the timecop gem to muck with time in our test suite. Hopefully, they’ll help you out if you stumble across this post. We get used to seeing broken tests, which means we might miss real problems. Sometimes they pass, sometimes they fail, and we can’t predict what will happen. They drive me nuts because it means we can’t fully trust the test suite. I’m deep in a codebase (Rails with RSpec and Cucumber) that has a variety of intermittent test failures. ![]()
0 Comments
Leave a Reply. |