-
Notifications
You must be signed in to change notification settings - Fork 69
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
vi-1055 Create UserActionEventsController and query route #20690
base: master
Are you sure you want to change the base?
Conversation
Error: A file (or its parent directories) does not have a CODEOWNERS entry. Please update the .github/CODEOWNERS file and add the entry for the Offending file: app/controllers/v0/user_action_events_controller.rb |
Error: A file (or its parent directories) does not have a CODEOWNERS entry. Please update the .github/CODEOWNERS file and add the entry for the Offending file: app/controllers/v0/user_action_events_controller.rb |
Error: A file (or its parent directories) does not have a CODEOWNERS entry. Please update the .github/CODEOWNERS file and add the entry for the Offending file: app/controllers/v0/user_action_events_controller.rb |
Error: A file (or its parent directories) does not have a CODEOWNERS entry. Please update the .github/CODEOWNERS file and add the entry for the Offending file: app/controllers/v0/user_action_events_controller.rb |
Error: A file (or its parent directories) does not have a CODEOWNERS entry. Please update the .github/CODEOWNERS file and add the entry for the Offending file: app/controllers/v0/user_action_events_controller.rb |
Error: A file (or its parent directories) does not have a CODEOWNERS entry. Please update the .github/CODEOWNERS file and add the entry for the Offending file: app/controllers/v0/user_action_events_controller.rb |
Error: A file (or its parent directories) does not have a CODEOWNERS entry. Please update the .github/CODEOWNERS file and add the entry for the Offending file: app/controllers/v0/user_action_events_controller.rb |
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.
When you declare subject { get(:index, params: index_params) }
at the top of the #index
method test that subject
invocation of the method is available in all of your nested contexts.
So everywhere that you're explicitly calling get :index, params: ...
you should be able to remove that and instead set the params ahead of time (since they'll show up in the index_params
arguments object) & then call the subject
to make the call happen. You'll only need to call it once per it
block so you should set it to a variable (like response = subject
) if you're planning on running lots of tests in an example.
# original way
context 'with some context' do
let(:start_date) { 3.months.ago.to_date }
let(:end_date) { 2.weeks.ago.to_date }
it 'does something' do
get :index, params: { start_date:, end_date: }
json_response = JSON.parse(response.body)['data']['data']
# with subject
context 'with some context' do
let(:start_date) { 3.months.ago.to_date }
let(:end_date) { 2.weeks.ago.to_date }
it 'does something' do
json_response = JSON.parse(subject.body)['data']['data']
let(:end_date) { 2.weeks.ago.to_date } | ||
|
||
it 'returns the results in descending order by created_at' do | ||
subject |
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.
You only need to call subject
once, so this test (and all of the other ones that have a line like this) can just begin with json_response = JSON.parse(subject.body)
and then you can set your expectations against that json_response
variable.
If you call the subject like that and set it to a variable then you won't need subject
or get :index
declared at the top of any of your tests.
Note: Delete the description statements, complete each step. None are optional, but can be justified as to why they cannot be completed as written. Provide known gaps to testing that may raise the risk of merging to production.
Summary
Related issue(s)
Testing done
#index
actionGo to http://localhost:3000/v0/user_action_events and we should see something like this as a result of default params when params are not provided:
And then we can change the start_date, end_date, page, per_page param in our
params
object to test the responses for different paramsWhat areas of the site does it impact?
Acceptance criteria