groceries/test_temporal_logic.md
lasse 0b42a74fe9 Minor version bump (1.x.0) is appropriate because:
 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)
2025-05-30 09:49:26 +02:00

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)