Stateless Code | Fix a Bug Where System Test Emails Need More Time to Complete @StatelessCode | Uploaded December 2022 | Updated October 2024, 30 minutes ago.
Wouldn't you know it? The one build where we merged the Devise epic into main failed with a similar issue to the one we fixed in the lock and unlock video. We brought this up as an action itme in our retro and it's the first of a handful of things we'll knock out before we start populating the backlog of actual features for our application.
Our GitHub issue has the steps to reproduce. We demonstrate in the video that the issue is reproducable. Rather than repeating the "sleep 0.1" statement all over our system test codebase, we create a reusable method that expects a block, calls yield to execute the block and then sleeps briefly. That way we can surround the code we want to execute in that block to make it clear that we need to wait for that block of code to finish before executing our next statement.
After we get the method working, we experiment a little to determine a good default value for the argument and find the other places in our existing tests to use the new method.
Adding these blocks makes one of our other methods a bit too long and complex, so RuboCop writes us a citation. We can break the method down a bit to refactor a few related statements into their own method.
Everything passes locally, but our build fails. Why? It turns out there was a new patch version of Ruby released since we released our last video. Our .ruby-version file specifies a patch level of 3.1.2, but our GitHub action only specifies the minor version 3.1. For the time being, we update our action to match the patch level and add an item to our backlog to update our patch version of Ruby for a separate video.
This video covers:
00:00:12 Introduction
00:04:05 Steps to reproduce the bug
00:05:26 Look at the test log to see what is happening
00:06:23 Look at the rest of the issue and explain intended solution
00:08:32 Create a reusable method that yields a block and then sleeps and replace the sleep call in the method from the previous test
00:11:41 Experiment to determine the default sleep value
00:12:40 Find the other tests that send emails and place them inside the block of the method
00:21:10 Fix RuboCop violations including refactoring a long method into a shorter one
00:25:45 Review the diff, commit push, build fails
00:29:33 Troubleshoot. Build failing due to new Ruby patch version. Specify current patch version in GitHub Actions and add Ruby upgrade to backlog.
#ruby #rails7 #rails #rubyonrails #rubygems #codecast #screencast #github #opensource #minitest #TDD #agile #NerdDice #DnD #roleplaying #softwaredevelopment #learntocode #tailwind #postgresql #rubocop #devise #turbo #controllers #views #selenium #capybara #systemtest #bugfix
See other related StatelessCode videos:
- NerdDice.com Retrospective 2 - User Authentication with Devise youtu.be/tFqHc8hRzuM
- Write Tests for User Locking and Unlocking and Finish the Devise Epic youtu.be/d-dHpSoU23Q
This video is CC0 - No rights reserved. (YouTube doesn't allow this option when publishing.) All code is released under the UNLICENSE. Stateless Code denies the concept of "intellectual property". Copying is not stealing.
Wouldn't you know it? The one build where we merged the Devise epic into main failed with a similar issue to the one we fixed in the lock and unlock video. We brought this up as an action itme in our retro and it's the first of a handful of things we'll knock out before we start populating the backlog of actual features for our application.
Our GitHub issue has the steps to reproduce. We demonstrate in the video that the issue is reproducable. Rather than repeating the "sleep 0.1" statement all over our system test codebase, we create a reusable method that expects a block, calls yield to execute the block and then sleeps briefly. That way we can surround the code we want to execute in that block to make it clear that we need to wait for that block of code to finish before executing our next statement.
After we get the method working, we experiment a little to determine a good default value for the argument and find the other places in our existing tests to use the new method.
Adding these blocks makes one of our other methods a bit too long and complex, so RuboCop writes us a citation. We can break the method down a bit to refactor a few related statements into their own method.
Everything passes locally, but our build fails. Why? It turns out there was a new patch version of Ruby released since we released our last video. Our .ruby-version file specifies a patch level of 3.1.2, but our GitHub action only specifies the minor version 3.1. For the time being, we update our action to match the patch level and add an item to our backlog to update our patch version of Ruby for a separate video.
This video covers:
00:00:12 Introduction
00:04:05 Steps to reproduce the bug
00:05:26 Look at the test log to see what is happening
00:06:23 Look at the rest of the issue and explain intended solution
00:08:32 Create a reusable method that yields a block and then sleeps and replace the sleep call in the method from the previous test
00:11:41 Experiment to determine the default sleep value
00:12:40 Find the other tests that send emails and place them inside the block of the method
00:21:10 Fix RuboCop violations including refactoring a long method into a shorter one
00:25:45 Review the diff, commit push, build fails
00:29:33 Troubleshoot. Build failing due to new Ruby patch version. Specify current patch version in GitHub Actions and add Ruby upgrade to backlog.
#ruby #rails7 #rails #rubyonrails #rubygems #codecast #screencast #github #opensource #minitest #TDD #agile #NerdDice #DnD #roleplaying #softwaredevelopment #learntocode #tailwind #postgresql #rubocop #devise #turbo #controllers #views #selenium #capybara #systemtest #bugfix
See other related StatelessCode videos:
- NerdDice.com Retrospective 2 - User Authentication with Devise youtu.be/tFqHc8hRzuM
- Write Tests for User Locking and Unlocking and Finish the Devise Epic youtu.be/d-dHpSoU23Q
This video is CC0 - No rights reserved. (YouTube doesn't allow this option when publishing.) All code is released under the UNLICENSE. Stateless Code denies the concept of "intellectual property". Copying is not stealing.
