Test Coverage Checklist for Enhanced Dynamo DB PRs #6067
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,59 @@ | ||
| # DynamoDB Enhanced Client Test Checklist | ||
|
|
||
| Below is the checklist required for merging DynamoDB Enhanced Client test changes. | ||
| Please complete this checklist when making any changes to Enhanced DDB. | ||
|
|
||
| **Instructions:** | ||
| - Mark completed tests with [x] (e.g., [x] instead of [ ]) | ||
| - For tests not completed, provide a reason in the "Comments" column | ||
| - If your code changes are covered by existing tests, reference the test class and method name in the Comments column (e.g., `TableSchemaTest.testFromBean()`) | ||
| - Please copy the markdown into your PR and update it in Testing section | ||
| - [Reference for CRUD Operations test](https://github.com/aws/aws-sdk-java-v2/blob/master/services-custom/dynamodb-enhanced/src/test/java/software/amazon/awssdk/enhanced/dynamodb/functionaltests/BasicCrudTest.java) | ||
| - [Reference for Data Types and Null Handling](https://github.com/aws/aws-sdk-java-v2/blob/master/services-custom/dynamodb-enhanced/src/test/java/software/amazon/awssdk/enhanced/dynamodb/document/EnhancedDocumentTestData.java) | ||
|
|
||
| ```md | ||
| ## Test Coverage Checklist | ||
|
|
||
| | Scenario | Done | Comments if Not Done | | ||
| |---------|:----:|---------------------| | ||
| | **1. Different TableSchema Creation Methods** | | | | ||
| | a. TableSchema.fromBean(Customer.class) | [ ] | | | ||
| | b. TableSchema.fromImmutableClass(Customer.class) for immutable classes | [ ] | | | ||
| | c. TableSchema.documentSchemaBuilder().build() | [ ] | | | ||
| | d. StaticTableSchema.builder(Customer.class) | [ ] | | | ||
| | **2. Nesting of Different TableSchema Types** | | | | ||
| | a. @DynamoDbBean with nested @DynamoDbBean as NonNull | [ ] | | | ||
|
There was a problem hiding this comment. As in null reference , updated to make it clear |
||
| | b. @DynamoDbBean with nested @DynamoDbImmutable as NonNull | [ ] | | | ||
| | c. @DynamoDbImmutable with nested @DynamoDbBean as NonNull | [ ] | | | ||
| | d. @DynamoDbBean with nested @DynamoDbBean as Null | [ ] | | | ||
| | e. @DynamoDbBean with nested @DynamoDbImmutable as Null| [ ] | | | ||
| | f. @DynamoDbImmutable with nested @DynamoDbBean as Null | [ ] | | | ||
| | **3. CRUD Operations** | | | | ||
| | a. scan() | [ ] | | | ||
| | b. query() | [ ] | | | ||
| | c. updateItem() | [ ] | | | ||
| | d. putItem() | [ ] | | | ||
| | e. getItem() | [ ] | | | ||
| | f. deleteItem() | [ ] | | | ||
| | g. batchGetItem() | [ ] | | | ||
| | h. batchWriteItem() | [ ] | | | ||
| | i. transactGetItems() | [ ] | | | ||
| | j. transactWriteItems() | [ ] | | | ||
| | **4. Data Types and Null Handling** | | | | ||
| | a. top-level null attributes | [ ] | | | ||
| | b. collections with null elements | [ ] | | | ||
| | c. maps with null values | [ ] | | | ||
| | d. conversion between null Java values and AttributeValue | [ ] | | | ||
| | e. full serialization/deserialization cycle with null values | [ ] | | | ||
|
There was a problem hiding this comment. As a DDB noob, I don't really know what this means... Can we point out to existing test cases or test classes? There was a problem hiding this comment. Updated a reference table also mentioned a link below |
||
| | **5. AsyncTable and SyncTable** | | | | ||
| | a. DynamoDbAsyncTable Testing | [ ] | | | ||
| | b. DynamoDbTable Testing | [ ] | | | ||
| | **6. New/Modification in Extensions** | | | | ||
| | a. Tables with Scenario in ScenarioSl No.1 (All table schemas are Must) | [ ] | | | ||
| | b. Test with Default Values in Annotations | [ ] | | | ||
| | c. Combination of Annotation and Builder passes extension | [ ] | | | ||
| | **7. New/Modification in Converters** | | | | ||
| | a. Tables with Scenario in ScenarioSl No.1 (All table schemas are Must) | [ ] | | | ||
| | b. Test with Default Values in Annotations | [ ] | | | ||
| | c. Test All Scenarios from 1 to 5 | [ ] | | | ||
| ``` | ||
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
Does it make sense to categorize the changes and specify tests required for each category?
For example:
...
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.
While initially I thought of categorizing it , but I believe we should maintain a comprehensive checklist approach rather than categorizing tests by change type. Here's why:
Most scenarios are already addressed in our test suite, but a comprehensive checklist approach helps us proactively identify gaps rather than discovering issues later in the development cycle.
For now, I think a complete checklist is more practical and ensures we don't miss anything important. We could consider developing a structured categorization approach in the future when we have time to properly map all test scenarios. What do you say?