Testing fundamentals

Testing and monitoring help you verify that an application is built correctly, behaves reliably, and can be diagnosed when something goes wrong. In KAIZEN, this combines browser debugging, structured error handling, HTTP status analysis, and consistent logging across the frontend and backend.

Debug KAIZEN applications during verification

Debugging is an important verification activity during development. It helps you isolate faults, inspect runtime state, and confirm whether the application follows the expected behaviour.

Use breakpoints to inspect the execution path

Use the browser developer tools Sources tab to pause JavaScript execution at a specific line. When the breakpoint is reached, the application stops at that instruction and allows you to inspect the current runtime environment.

While paused, use the Scope pane to review local variables, closure variables, and other values available at that point in the execution flow. This is useful when you need to confirm whether the correct data is being passed between functions, whether a condition is evaluated as expected, or whether the application state has changed unexpectedly.

Use the console for dynamic state analysis

The Console tab provides an interactive way to inspect and test application behaviour. You can use console.log() to trace the execution path, print variable values, and observe how data changes over time.

For deeper debugging, you can also inspect accessible component variables or application-level objects directly from the console. This helps you test a hypothesis quickly, such as whether a missing value, incorrect response, or invalid state is causing the issue.

Simulate environment constraints

Some issues only appear under slower or less stable conditions. Use the Network tab to throttle network speed and test how the application behaves with delayed responses. This is useful for verifying loading states, asynchronous processing, retries, and timeout handling.

Use the Application tab to inspect and manage browser storage such as Local Storage and Session Storage. This helps isolate issues related to cached data, session state, authentication tokens, and stale values retained by the browser.

Handle errors with fault tolerance

Error handling should be treated as part of the application's fault tolerance strategy. A well-handled error prevents a local failure from becoming a wider system failure and helps preserve a professional user experience.

KAIZEN supports the following error handling approaches:

Configuration	Behaviour	Recommended Usage
forwardError	Transfers control internally to a designated error view without changing the browser URL.	Use for internal application exceptions where the stack trace, HTTP request/response details, and associated application variables should be preserved for logging and diagnosis.
toErrorPage	Redirects the browser to a separate error page, causing a URL change and a new request cycle.	Use for general, security-related, or non-recoverable failures where immediate redirection is more important than preserving runtime context.

For custom application logic, use structured exception handling such as try-catch blocks. This allows the application to degrade gracefully when predictable failures occur, such as a service being temporarily unavailable or a submitted value failing validation.

Instead of allowing the page to fail silently or crash, return a controlled response. Examples include showing a clear notification, logging the failure, retrying the operation when appropriate, or routing the user to a safe fallback page.

Diagnose common HTTP status codes

HTTP status codes help identify where a fault may originate in a client-server request. When troubleshooting KAIZEN applications, start by checking the failed request in the browser Network tab, then compare the request details with server-side configuration and logs.

Code	Meaning	Troubleshoot Strategy
401 Unauthorised	The request requires valid authentication credentials, but the credentials are missing, expired, or invalid.	Check the Authorisation header, session cookies, token validity, and browser storage used for authentication state.
403 Forbidden	The user is authenticated, but does not have permission to access the requested resource.	Review the user's role, permissions, and access control rules for the endpoint and request method.
404 Not Found	The requested resource or route cannot be found.	Verify the request URL in the Network tab, confirm the correct environment is selected (e.g., via Profile connected), and check whether the backend service is deployed and routed correctly.
406 Not Acceptable	The request cannot be fulfilled because the required permissions or acceptable response conditions are not met.	Confirm the user's IAM roles, required privileges, accepted media type, and related access control policies.
500 Internal Server Error	The server encountered an unexpected processing error.	Review backend application logs and stack traces to identify the failing service, operation, or implementation logic.

Apply observability and logging practices

Observability is the ability to understand the internal state of a system based on the data it exposes. Logging is a key part of observability because it provides the diagnostic trail needed to reconstruct what happened before, during, and after a fault.

Frontend logging

Frontend (FE) logs should help reconstruct the user journey. Log important state transitions such as component rendering, form submission, asynchronous data loading, and route changes.

A session ID and user ID must be included, so related events can be traced together. For client-side exceptions, enrich the log with useful context such as the component hierarchy, browser and operating system information, and masked authentication state.

Log messages must be clear and self-contained. For example:

FE_ERROR: Component Navbar failed to render due to missing UserProfile object.

Backend logging

Backend (BE) logs must be structured and machine-readable, preferably in JSON format. Structured logs make it easier for monitoring tools to search, aggregate, filter, and analyse production behaviour.

For example:

{
  "level": "ERROR",
  "operation": "DB_WRITE",
  "latency_ms": 450,
  "request_id": "REQ-12345"
}

Every transaction must have a unique correlation ID or request ID created at the entry point, such as an API gateway. This ID must be passed to downstream services and included in every related log entry so the full request path can be traced across the system.

Use log levels consistently. Production environments should minimise DEBUG logging to avoid unnecessary performance overhead and reduce noise during incident analysis.

Finally, logs must be sanitised before they are stored or transmitted. Do not log any passwords, personal data, access tokens, cryptographic keys, or other confidential values.

Last updated on 19 Oct 2026