-
Notifications
You must be signed in to change notification settings - Fork 166
Log ThreatMetrix status on IPP events #10101
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
deea575
53f493c
76c3c77
7a95b9f
24edfd0
7cd4c08
21c6899
b988652
4fc312c
f685f9a
5b1ebf1
939740f
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This looks good, but I would like to see a single test where the
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I discussed this with @n1zyy before when I asked for guidance on new tests I was considering writing and how far down the rabbit hole I should go.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That's a good point. I think it's fine to leave as is then.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I think your read here, and above on analytics, is a good one. At some point we should make |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think we should add a test that shows
tmx_statusgetting logged in a analytics eventThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh oops, I see lower down there's a convo about this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh wait scratch that, on re-read I think that's specifically about the
enrollment_helperfile. In that case my comment still stands.Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So I think what actually might be my preferred solution here, and doesn't conflate concerns, is to write some tests in
profile_spec.rbthat test the helper. I should have done that when pulling the logic out into a separate helper method, probably, but I overlooked it because it was getting inadvertently tested everywhere it's implemented. But if we trust that the helper method in profile works appropriately, and we trust that the model for profile works appropriately, and we trust that the the analytics helper logs things appropriately, how important is it to have separate testing for each class consuming a method for a log event to test the output specifically?On the other hand, maybe the answer is it is important, and I should do both. Including adding logic for
profiletoenrollment_helper_spec. I just think if we continue to add "logs x characteristic specifically" the test files will get a lot heavier. Should we test every combination? But we already have that precedent somewhat.Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Btw the analytics event does show up in the tests. They fail unless I accommodate the new log output. The output shows
tmx_status: :threatmetrix_passedin theget_usps_proofing_results_job_specand astmx_status: nilinenrollment_helper_specbecause a profile is not defined.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think that makes sense. Our convention has been to add the additional property to more of the analytics tests but I do agree with you that is does add a lot to the file (perhaps unnecessarily?).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
also might be an interesting topic for eng huddle - lightening our test files by reducing some redundancy
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm of the opinion that if things are being tested elsewhere, then no need to duplicate the tests. I think it is good to be explicit, but if you can point to a spec that is already covering the particular thing you want to test, then maybe that's enough? But IDK, I think this warrants a broader discussion (but I mean that discussion to take place outside of the scope of this ticket). So I second @svalexander's point above