Stateless Code | Write System Tests for Devise Reconfirm Email and Refactor Shared Code into a Testing Concern @StatelessCode | Uploaded November 2022 | Updated October 2024, 1 hour ago.
In this video we build upon what we did in our last video where we allowed users to change and confirm their email addresses. Now we will write tests for the situation where a user needs to reconfirm an email address.
In the introduction we note that we will likely need to break the change email and reconfirm email into separate test classes to keep our classes focused and their size manageable. At least to begin with we add new test cases into the existing ChangeEmailTest class.
We start by building off of the situation we already tested where an email will not be confirmed if you visit the confirmation URL with an invalid confirmation token. That left us right at the Resend confirmation instructions page. We pick up there, fill in the field with the email address we need and test the ability to reconfirm from that context.
After that we test the ability of the user to resend the email confirmation using either the old email or the new email. We run into a little bit of trouble here because the journey is slightly different depending on whether or not the user is currently logged in. We use the test screenshot that write to our tmp/screenshots folder in order to diagnose and correct the failing tests.
At this point we have a lot of duplication that we can refactor into smaller helper methods. Even after refactoring, RuboCop fusses at us because the test class is to big. We split the class into ChangeEmailTest and ReconfirmEmailTest, but then we have the same private helper methods duplicated in both classes. The functionality is specific to changing emails, so we don't want to put all of that shared code directly into ApplicationSystemTestCase. Instead we decide to place the shared helper methods into a Ruby module that extends ActiveSupport::Concern and then include that module in both test classes.
This video covers:
00:00:12 Introduction
00:03:14 Demonstrate the functionality to be tested
00:08:39 Fix missing square bracket from previous video
00:09:13 Overview of the new test functionality we plan to add
00:10:18 Implement reconfirm after invalid token
00:12:53 Refactor out repeated code between confirm happy path and reconfirm test
00:14:46 Write and troubleshoot tests for not logged in reconfirm scenarios and adapt valid_confirmation! method to handle logged in and logged out scenarios
00:26:57 RuboCop shoots our dog. First sweep of refactoring repeated code.
00:30:16 Troubleshoot inexplicable test failure that we are unable to reproduce. Won't even fail again if you use the same seed.
00:35:52 Class too long. Split into ChangeEmailTest and ReconfirmEmailTest
00:42:18 Move shared helper methods into a testing concern that is included by both test classes
00:48:18 Write comments for the methods in the testing concern
00:49:57 Refactor out shared setup block code into method in the testing concern, and specify the scope of the constant
00:54:03 Change name of testing concern
00:55:25 Review, commit, push, update project
#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 #concerns
See other related StatelessCode videos:
- Getting Started with Rails 7 16: Refactor Repeated Code Using Concerns youtu.be/9M_079-mppo
- Write System Tests for Devise User to Change Email youtu.be/-GFl4UaMIKI
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.
In this video we build upon what we did in our last video where we allowed users to change and confirm their email addresses. Now we will write tests for the situation where a user needs to reconfirm an email address.
In the introduction we note that we will likely need to break the change email and reconfirm email into separate test classes to keep our classes focused and their size manageable. At least to begin with we add new test cases into the existing ChangeEmailTest class.
We start by building off of the situation we already tested where an email will not be confirmed if you visit the confirmation URL with an invalid confirmation token. That left us right at the Resend confirmation instructions page. We pick up there, fill in the field with the email address we need and test the ability to reconfirm from that context.
After that we test the ability of the user to resend the email confirmation using either the old email or the new email. We run into a little bit of trouble here because the journey is slightly different depending on whether or not the user is currently logged in. We use the test screenshot that write to our tmp/screenshots folder in order to diagnose and correct the failing tests.
At this point we have a lot of duplication that we can refactor into smaller helper methods. Even after refactoring, RuboCop fusses at us because the test class is to big. We split the class into ChangeEmailTest and ReconfirmEmailTest, but then we have the same private helper methods duplicated in both classes. The functionality is specific to changing emails, so we don't want to put all of that shared code directly into ApplicationSystemTestCase. Instead we decide to place the shared helper methods into a Ruby module that extends ActiveSupport::Concern and then include that module in both test classes.
This video covers:
00:00:12 Introduction
00:03:14 Demonstrate the functionality to be tested
00:08:39 Fix missing square bracket from previous video
00:09:13 Overview of the new test functionality we plan to add
00:10:18 Implement reconfirm after invalid token
00:12:53 Refactor out repeated code between confirm happy path and reconfirm test
00:14:46 Write and troubleshoot tests for not logged in reconfirm scenarios and adapt valid_confirmation! method to handle logged in and logged out scenarios
00:26:57 RuboCop shoots our dog. First sweep of refactoring repeated code.
00:30:16 Troubleshoot inexplicable test failure that we are unable to reproduce. Won't even fail again if you use the same seed.
00:35:52 Class too long. Split into ChangeEmailTest and ReconfirmEmailTest
00:42:18 Move shared helper methods into a testing concern that is included by both test classes
00:48:18 Write comments for the methods in the testing concern
00:49:57 Refactor out shared setup block code into method in the testing concern, and specify the scope of the constant
00:54:03 Change name of testing concern
00:55:25 Review, commit, push, update project
#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 #concerns
See other related StatelessCode videos:
- Getting Started with Rails 7 16: Refactor Repeated Code Using Concerns youtu.be/9M_079-mppo
- Write System Tests for Devise User to Change Email youtu.be/-GFl4UaMIKI
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.
