lasse
0b42a74fe9
✅ 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)
3.3 KiB
3.3 KiB
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:
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:
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:
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:
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:
- Manual versioning (since valid_from was specified):
- Create history record with old data
- Set history.valid_to = new.valid_from
Database Result:
-- 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:
products: id=1, name="Milk", weight=1200, valid_from='2025-01-12', valid_to='9999-12-31'
API Call (no valid_from specified):
PUT /products/1
{
"name": "Organic Milk"
}
Backend Processing:
- 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:
-- 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)