We'd like to have a consistent and safe way for study designers (almost always the implementers, so people with the DEVELOPER role) to delete and remove things as they set up a study. Often our delete APIs remove things from the database, and so those calls are only accessible to administrators for test clean-up.
...
- If item is already logically deleted, throw an EntityNotFoundException (deletingLogicallyDeletedAppleThrows)
- If item is not marked deleted, mark it as deleted (logicallyDeletingAppleWorks)
...
- If item is not in database, throw an EntityNotFoundException (physicallyDeletingMissingAppleThrows)
- If item is in database but logically deleted, this should physically delete the item (physicallyDeletingLogicallyDeletedAppleWorks)
...
| Name | What we should test |
|---|---|
| getAppleIncludesLogicallyDeleted | The get apple call returns logically deleted apples |
| getApplesIncludes/ExcludesLogicallyDeleted | The apple collection calls include or exclude logically deleted apples based on the flag |
| createAppleCannotBeDeleted | Creating an apple with deleted=true just creates the apple with deleted=false |
| updateLogicallyDeletedAppleThrows | Cannot update if saved and updated apple are both deleted=true |
| updateCanUndeleteApple | saved apple deleted=true, updated apple deleted=false works |
| updateCanDeleteApple | saved apple deleted=false, updated apple deleted=true works (no reason to prevent it) |
| logicallyDeletingLogicallyDeletedAppleThrowsdeleteLogicallyDeletedAppleThrows | Cannot delete an apple that is already deleted |
| deleteApple | Can logically delete an apple |
| deleteAppleMissingAppleThrows | Trying to logically delete a logically deleted apple throws |
| deleteApplePermanently | Can permanently delete an apple |
| deletePermanentlyLogicallyDeletedApple | Can physically delete an apple that is logically deleted (rather than getting a 404) |
| deletePermanentlyMissingAppleThrows |
...