Hi @woodyza, thanks for this! I'm taking a look at the code today.

should there be a higher-level test that triggers throughput exceeded for e.g. to cover regressions on the higher-level requirement

Yes, we would like end-to-end tests through all affected high-level clients as well.

Sweet thanks @mattsb42-aws - I'll get onto these later on today.

Btw any pointers toward where the higher-level tests would best be implemented? I'm still figuring out the structure of the tests and how they interact with tox and the different test runs. Bit of a tox n00b tbh, don't spend a lot of time on library code that needs to work on more than one python version or platform.

Sweet thanks @mattsb42-aws - I'll get onto these later on today.

Btw any pointers toward where the higher-level tests would best be implemented? I'm still figuring out the structure of the tests and how they interact with tox and the different test runs. Bit of a tox n00b tbh, don't spend a lot of time on library code that needs to work on more than one python version or platform.

The categories are described here[1]. Notably:

• functional: mark test as a functional test (does not require network access)
• integ: mark a test as an integration test (requires network access)
• ddb_integ: mark a test as an integration test that requires a real DynamoDB table (requires network access and not used in CI)

What I would have in mind for end-to-end tests for this behavior would be functional tests that mock out the DDB client. Unless you can figure out how to get moto to not process certain items, in which case functional tests that use that.

[1] https://github.com/aws/aws-dynamodb-encryption-python/blob/master/setup.cfg#L17-L30

@mattsb42-aws I think I've tackled all your comments so far, I'm just jumping into the e2e tests now.

Thanks of the contribution! I'll update #91 and #92 once we have this published in a new version.

No probs! Thanks for the patient reviewing 😄

@woodyza 1.1.0 is now live with these changes.