Testing & QA

Overview

Testing the Atslegas system focuses on two critical areas: ensuring the integrity of the RESTful API and validating the reliability of the SQLite database under concurrent load. Since the application handles physical key management, it is essential to verify that session security and database locks behave correctly during simultaneous access.

API Validation

The backend is built on a RESTful architecture using Flask blueprints. You can validate the API endpoints using tools like curl, Postman, or automated Python scripts.

Authentication & Session Testing

To verify the authentication flow and session timeout logic:

1. Login Request: Send a POST request to /api/login_req with valid credentials.
2. Session Persistence: Verify that the session cookie is returned and stored.
3. Timeout Verification: The application uses a configurable timeout (default: 3600s). You can test the automatic session clearing by setting the timeout_seconds in config.json to a low value (e.g., 30) and waiting for the session to expire.

Example API test using curl:

curl -X POST http://localhost:5000/api/login_req \
     -H "Content-Type: application/json" \
     -d '{"username": "root", "password": "root"}'

Endpoint Integrity

All API responses follow a standard JSON format:

• Success: {"success": true, "data": [...]}
• Error: {"success": false, "error": "Reason for failure"}

When testing endpoints like /api/user/list or /api/keyGroup/add, ensure that unauthorized requests (those without a valid session cookie) receive a 401 Unauthorized response.

Database Concurrency Testing

Atslegas uses SQLite in WAL (Write-Ahead Logging) mode with a custom retry mechanism (execute_write_with_retry) to handle simultaneous write operations. Testing concurrency is vital to ensure the application does not crash when multiple admins or users update records at the same time.

Running Concurrency Tests

To validate the database engine's handling of locks:

1. Simulated High Load: Run multiple instances of a script that attempts to write to the user or userData tables simultaneously.
2. Busy Timeout Verification: The system is configured with a PRAGMA busy_timeout = 5000. Tests should confirm that processes wait up to 5 seconds for a lock to release before failing.
3. Retry Logic: Verify that the backoff mechanism in db_engine.py successfully recovers from database is locked errors.

Manual Database Verification

You can inspect the database state after running automated tests using the SQLite CLI:

sqlite3 database.db
# Check for WAL integrity
PRAGMA journal_mode;
# Verify user counts
SELECT COUNT(*) FROM user;

Frontend & UI Testing

The frontend utilizes asynchronous XMLHttpRequest calls to populate data. QA should focus on the synchronization between the local storage cache and the server state.

UI Consistency Checks

• Data Loading: Ensure loadData() in admin-common.js correctly populates globalData from the API.
• State Management: Verify that after adding a key or group in the Admin Dashboard, the init_renderall() function triggers a UI refresh without requiring a manual page reload.
• Calendar Logic: Validate that the renderCalendar() function in admin-dashboard.js correctly maps keyLogs to the specific dates and displays the "Izsniegti" (Issued) and "Atgriezti" (Returned) badges accurately.

Browser Console Debugging

The application includes built-in logging. During QA, monitor the browser console for:

• Loading data from API and localStorage...
• Errors within checkAllRequestsComplete() if an API endpoint fails to respond.

QA Environment Configuration

For testing purposes, it is recommended to use a separate database file. Modify your config.json before running tests:

{
    "db": {
        "db_file": "test_database.db",
        "schema_file": "schema.sql"
    }
}

This ensures your production data remains intact while validating new features or running high-concurrency scripts.