Skip to content
This repository was archived by the owner on Dec 3, 2019. It is now read-only.

Conversation

@BRIMIL01
Copy link
Contributor

@BRIMIL01 BRIMIL01 commented Oct 6, 2018

Description of changes

Swaps out use of assert with assert_equals and fixed a timezone issue when running tests locally.

Based off #421

get api_v1_airtable_mentorships_path, headers: @headers, as: :json

assert response.status == 200
assert_equal response.status, 200
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this out of order if format is:
assert_equal {expected}, {actual}

Does it matter if it's reversed?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I may have phoned it in a bit at the end

assert response.dig('fields', 'Skillsets') == [request_body[:skillsets]]
assert response.dig('fields', 'Additional Details') == request_body[:additional_details]
assert response.dig('fields', 'Mentor Requested') == [request_body[:mentor_requested]]
assert_equal request_body[:slack_user], response.dig('fields', 'Slack User')
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this looks like {actual}, {expected}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is actually correct, the request_body is the hash of expected values.

assert pr['number'] == @pr_number
assert pr['title'] == 'Revert "waffle.io Badge"'
assert pr['state'] == 'closed'
assert_equal 200, response.code.to_i
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This appears to be
{expected}, {actual}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is correct

assert response.headers['X-RateLimit-Limit'] == '60'
assert response.headers['X-RateLimit-Reset'] == '1503866476'
assert @client.send(:reset_time, response) == '8/27/2017 at 8:41:16pm UTC'
reset_time = Time.at(1503866476).strftime '%-m/%d/%Y at%l:%M:%S%P %Z'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How does this break test runs?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When running locally it uses the local time zone when generating the timestamp which doesn’t match the expected value which is UTC.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I remember that sometimes the rate limiting test messes things up. We should probably have a way of testing rate limiting.

Why is this done instead of some other way?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can pull in something like timecop to manage the expected timezone

Copy link
Member

@apex-omontgomery apex-omontgomery left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LG2M

@apex-omontgomery apex-omontgomery merged commit 20fae19 into OperationCode:master Oct 10, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants