Fix effect on target regions of assuming_session

[iainelder]

Change the host account init to pass these tests:

• test_when_no_default_region_then_cove_uses_assuming_session_region
• test_cove_prefers_assuming_session_region

A side effect of the change is even if the caller doesn't specify a target region then the cove result includes a Region key. (PR #79 shows how to avoid that side effect, but it's simpler to accept it.)

Set the default region for all tests to allow me to test for that side effect. A real user will always set the region from a profile or an environment variable if one isn't passed explicitly to botocove.

The default region forces me to update the test_regions module. Without setting a default region, the old test still passed!

• Old: test_when_region_is_unspecified_then_result_has_no_region_key
• New: test_when_region_is_unspecified_then_result_has_default_region_key

The default region makes a Region key appear in tests that check the whole cove output instead of a single feature. Later I'll refactor these tests because it's not clear what feature they cover.

The default region is eu-west-1 and all region arguments use some other value such as eu-central-1 or us-east-1. This convention makes the tests easier to read.

Use the _no_default_region fixture when you really need to test how cove behaves without the default region.

Using the _org_with_one_member fixture and the raise_exception=True parameter together make the tests easier to write because you can assume the cove output has a single result and no exceptions. If any exception occurs, use pytest.raises to detect it. Later I'll refactor more tests to use this calling style. We can use dedicated test modules to cover the behavior of raise_exception=False and of an organization with multiple accounts.

This paves the way to querying the opt-in regions in #77.

[connelldave]

lgtm - merging now for future release, but I think the changelog here is broadly "reports current region rather than None when region is unset"

[iainelder]

@connelldave Thanks for merging this.

I think now we're just one PR away from resolving #74 .

I haven't had much time to work on any open source stuff lately, but it's still in my queue :-)