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

auroradns: Implement iterator for zones and records #829

Closed
wants to merge 1 commit into
base: trunk
from

Conversation

Projects
None yet
3 participants
@wido
Contributor

wido commented Jul 2, 2016

By implementing iterate_zones() and iterate_records() you can
iterate over zones and records returned by the API.

The list_zones() and list_records() methods simply talk to the
iteration functions and create a list of it and return that.

The test cases should still match since they call the list functions
and those call the iterators on their turn.

@tonybaloney

This comment has been minimized.

Show comment
Hide comment
@tonybaloney

tonybaloney Jul 5, 2016

Contributor

thanks @wido it would be great to update the test case to validate that the responses are infact tuples or iterate the responses. the current case I think just checks the first response.
e.g.
assertEqual(tuple(generator_object), (1, 2, ...))

Contributor

tonybaloney commented Jul 5, 2016

thanks @wido it would be great to update the test case to validate that the responses are infact tuples or iterate the responses. the current case I think just checks the first response.
e.g.
assertEqual(tuple(generator_object), (1, 2, ...))

auroradns: Implement iterator for zones and records
By implementing iterate_zones() and iterate_records() you can
iterate over zones and records returned by the API.

The list_zones() and list_records() methods simply talk to the
iteration functions and create a list of it and return that.

The test cases should still match since they call the list functions
and those call the iterators on their turn.

The test case test_list_zones() however has been expanded to iterate
over the result.

The test_list_records case already iterated over the results, so that
verifies that the result is iteratable.
@wido

This comment has been minimized.

Show comment
Hide comment
@wido

wido Jul 5, 2016

Contributor

@tonybaloney Thanks for the feedback! I expanded one test-case slightly, but the records were already iterated.

Or I might be missing your point here. But the list_records/zones calls call the iterate functions, so that tests it from beginning to end, right?

Contributor

wido commented Jul 5, 2016

@tonybaloney Thanks for the feedback! I expanded one test-case slightly, but the records were already iterated.

Or I might be missing your point here. But the list_records/zones calls call the iterate functions, so that tests it from beginning to end, right?

@tonybaloney

This comment has been minimized.

Show comment
Hide comment
@tonybaloney

tonybaloney Jul 6, 2016

Contributor

cool, 👍 then. you need to make sure you make multiple assertions for a generator method, that was all I was suggesting.

Contributor

tonybaloney commented Jul 6, 2016

cool, 👍 then. you need to make sure you make multiple assertions for a generator method, that was all I was suggesting.

@asfgit asfgit closed this in 29698de Jul 6, 2016

asfgit pushed a commit that referenced this pull request Jul 6, 2016

@Kami

This comment has been minimized.

Show comment
Hide comment
@Kami

Kami Jul 10, 2016

Member

Thanks for this change.

I know I am a bit late, but anyway. I removed the list_* methods from the driver since they are a bit redundant - they are already implemented on the base driver (52b037b).

Member

Kami commented Jul 10, 2016

Thanks for this change.

I know I am a bit late, but anyway. I removed the list_* methods from the driver since they are a bit redundant - they are already implemented on the base driver (52b037b).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment