Refactor 2FA setup controller specs

[aduth]

🎫 Ticket

Supports LG-14655

🛠 Summary of changes

Refactors specs for Users::TwoFactorAuthenticationSetupController#create.

Specific improvements:

• Update describe description to follow conventions for controller action method names ('PATCH create' ➡️ '#create')
• Remove duplicate assertions for expected analytics logging
• Avoid testing internal implementation details irrelevant for expected outcomes (asserting that form class is called)
• Reduce boilerplate, using combination of subject and before common setup
• Leverage RSpec one-liner syntax to simplify redirect expectations
• Add test coverage for expected error message on invalid submission

This is split from the work of LG-14655, which requires revisions to these controller specs building upon the improvements here.

📜 Testing Plan

rspec spec/controllers/users/two_factor_authentication_setup_controller_spec.rb

[kevinsmaster5]

Looks good and more efficient 👍

[vrajmohan]

Something I never got to the bottom of as some links are busted - https://www.betterspecs.org/#expect.

[aduth]

@vrajmohan Yeah it occurred to me after submitting that the one-liner documentation talks about should short-hand using the older syntax. I think we should probably use the is_expected.to syntax, but it also bothers me that it's several more characters in length 😅

Also, in the broader conversation of "should" vs. "expect", I think standardization is much more relevant and impactful when not using the one-liner syntax, since the non-one-liner impacts how the code is read much more than with the one-liner syntax.

expect(some_computed_value).to eq(42)
some_computed_value.should eq(42)

# vs...

it { should eq(42) }
it { is_expected.to eq(42) }

Not really a hill I'd die on either way. 🤷

[aduth]

Updated from should to expect syntax in 01b0fde.