Conversation
Avoid double-visiting, awkward "skip" exclusion which is too easy to forget
changelog: Internal, Automated Testing, Improve automated testing performance
| agent = instance_double(Idv::Agent) | ||
| allow(Idv::Agent).to receive(:new).and_return(agent) | ||
| allow(agent).to receive(:proof_resolution).and_return( | ||
| success: true, errors: {}, context: { stages: [] }, | ||
| ) |
There was a problem hiding this comment.
❤️ thank you for removing all these stubs on .new
| it 'does not perform the state ID check' do | ||
| allow(IdentityConfig.store).to receive(:aamva_sp_banlist_issuers). | ||
| and_return('["urn:gov:gsa:openidconnect:sp:server"]') | ||
| expect_any_instance_of(Idv::Agent). |
There was a problem hiding this comment.
expect_any_instance_of is not my favorite, but given that these are feature specs we don't have much of a choice 😬 and I'd rather have this than stub .new 🤷
There was a problem hiding this comment.
expect_any_instance_ofis not my favorite
Curious: Could you elaborate on why you'd avoid it?
There was a problem hiding this comment.
Like as is, this is just syntactic sugar over stubbing .new,
In something like a unit test, I'd be able to inject a specific instance to the class we're testing, so I could test that instance, to prevent confusion or test pollution when like, there should maybe be separate Idv::Agent instances or something.
A little testing aphorism I like is "don't stub what you don't own", so if this was a unit test I'd write it like...
step = VerifyStep.new
allow(step).to receive(:idv_agent).and_return(double('Idv::Agent'))
expect(idv_agent).to receive().....
step.call(....)There was a problem hiding this comment.
Ah, I see what you mean now, and I see how feature specs in particular may not be particularly well suited for the ideal implementation. Thanks for explaining 👍
2 participants
Why:
skip_step_completionoption. Since that's easy to miss, the workaround here was to remove it and inline the preparation in each spec.DocAuthLogwas actually referencing a different user than the one which had just submitted the form, since that sign in was not the same as the one in the initial test preparationDocAuthLog#aamvafor one of the three AAMVA-related specsApplicationController#analyticsrather than for each individual spec