✅ New functionality added (soft delete system) ✅ Backward compatible (existing features unchanged) ✅ Significant enhancement (complete temporal tracking system) ✅ API additions (new endpoints, parameters) ✅ UI enhancements (new components, visual indicators)
127 lines
3.3 KiB
Markdown
127 lines
3.3 KiB
Markdown
# Temporal Logic Test Scenarios
|
|
|
|
## Test Case 1: Add New Product
|
|
|
|
### Frontend Behavior:
|
|
- **Default valid_from**: Today's date (e.g., 2025-01-15)
|
|
- **User constraint**: Can edit to any date <= today
|
|
- **Date picker**: max="2025-01-15", no min restriction
|
|
|
|
### API Call:
|
|
```json
|
|
POST /products/
|
|
{
|
|
"name": "New Milk",
|
|
"category_id": 1,
|
|
"weight": 1000,
|
|
"valid_from": "2025-01-10" // User chose 5 days ago
|
|
}
|
|
```
|
|
|
|
### Backend Validation:
|
|
- ✅ valid_from <= today (2025-01-10 <= 2025-01-15)
|
|
|
|
### Database Result:
|
|
```sql
|
|
products: id=1, name="New Milk", weight=1000, valid_from='2025-01-10', valid_to='9999-12-31'
|
|
```
|
|
|
|
---
|
|
|
|
## Test Case 2: Edit Existing Product
|
|
|
|
### Current State:
|
|
```sql
|
|
products: id=1, name="Milk", weight=1000, valid_from='2025-01-10', valid_to='9999-12-31'
|
|
```
|
|
|
|
### Frontend Behavior:
|
|
- **Fetch current valid_from**: API call to `/products/1/valid-from` → "2025-01-10"
|
|
- **Default valid_from**: Today's date (2025-01-15)
|
|
- **User constraint**: Can edit to any date > 2025-01-10 AND <= today
|
|
- **Date picker**: min="2025-01-10", max="2025-01-15"
|
|
|
|
### API Call:
|
|
```json
|
|
PUT /products/1
|
|
{
|
|
"weight": 1200,
|
|
"valid_from": "2025-01-12" // User chose 2 days after current valid_from
|
|
}
|
|
```
|
|
|
|
### Backend Validation:
|
|
- ✅ valid_from <= today (2025-01-12 <= 2025-01-15)
|
|
- ✅ valid_from > current_valid_from (2025-01-12 > 2025-01-10)
|
|
|
|
### Backend Processing:
|
|
1. **Manual versioning** (since valid_from was specified):
|
|
- Create history record with old data
|
|
- Set history.valid_to = new.valid_from
|
|
|
|
### Database Result:
|
|
```sql
|
|
-- History table gets the old version
|
|
products_history:
|
|
id=1, name="Milk", weight=1000,
|
|
valid_from='2025-01-10', valid_to='2025-01-12', operation='U'
|
|
|
|
-- Current table gets updated version
|
|
products:
|
|
id=1, name="Milk", weight=1200,
|
|
valid_from='2025-01-12', valid_to='9999-12-31'
|
|
```
|
|
|
|
---
|
|
|
|
## Test Case 3: Edit Without Custom Date (Automatic Versioning)
|
|
|
|
### Current State:
|
|
```sql
|
|
products: id=1, name="Milk", weight=1200, valid_from='2025-01-12', valid_to='9999-12-31'
|
|
```
|
|
|
|
### API Call (no valid_from specified):
|
|
```json
|
|
PUT /products/1
|
|
{
|
|
"name": "Organic Milk"
|
|
}
|
|
```
|
|
|
|
### Backend Processing:
|
|
1. **Automatic versioning** (trigger handles it):
|
|
- Trigger detects OLD.valid_from = NEW.valid_from
|
|
- Trigger creates history with valid_to = CURRENT_DATE
|
|
- Trigger sets NEW.valid_from = CURRENT_DATE
|
|
|
|
### Database Result:
|
|
```sql
|
|
-- History table gets the old version (trigger created)
|
|
products_history:
|
|
id=1, name="Milk", weight=1200,
|
|
valid_from='2025-01-12', valid_to='2025-01-15', operation='U'
|
|
|
|
-- Current table gets updated version (trigger set dates)
|
|
products:
|
|
id=1, name="Organic Milk", weight=1200,
|
|
valid_from='2025-01-15', valid_to='9999-12-31'
|
|
```
|
|
|
|
---
|
|
|
|
## Validation Rules Summary
|
|
|
|
### For New Products:
|
|
- ✅ Frontend: valid_from <= today
|
|
- ✅ Backend: valid_from <= today
|
|
|
|
### For Existing Products:
|
|
- ✅ Frontend: current_valid_from < valid_from <= today
|
|
- ✅ Backend: current_valid_from < valid_from <= today
|
|
- ✅ Manual versioning: history.valid_to = new.valid_from
|
|
- ✅ Automatic versioning: history.valid_to = CURRENT_DATE
|
|
|
|
### Database Trigger Logic:
|
|
- **Manual versioning**: When OLD.valid_from ≠ NEW.valid_from (app handles history)
|
|
- **Automatic versioning**: When OLD.valid_from = NEW.valid_from (trigger handles history) |