BodegaX follows a multi-layered testing strategy that covers unit tests at the Angular component level, API contract validation, end-to-end UI automation, load testing, and security scanning. Every module — authentication, inventory, orders, user administration, and reporting — has defined test cases with explicit inputs and expected outcomes, ensuring the application reaches production in a verified and stable state.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/Edwin950821/BodegaX/llms.txt
Use this file to discover all available pages before exploring further.
Test Environment Setup
The Angular frontend uses Karma as the test runner paired with the Jasmine behavior-driven framework. Both are installed as dev dependencies inpackage.json alongside Chrome Launcher (for headless browser execution), a coverage reporter, and an HTML reporter.
| Package | Version |
|---|---|
karma | ~6.4.0 |
karma-jasmine | ~5.1.0 |
karma-chrome-launcher | ~3.2.0 |
karma-coverage | ~2.2.0 |
karma-jasmine-html-reporter | ~2.1.0 |
jasmine-core | ~5.1.0 |
@types/jasmine | ~5.1.0 |
Running the Test Suite
Run all unit tests
Execute the full Jasmine test suite via the Angular CLI script defined in Karma launches a Chrome instance, runs every
package.json:.spec.ts file it finds, and streams pass/fail results to the terminal.After running
ng test --code-coverage, open coverage/bodega-x-angular/index.html in your browser to explore line-by-line coverage for every component and service. Aim for 100% coverage on critical auth and guard logic.Spec File Structure
Each Angular component and service ships with a corresponding.spec.ts file. Below are two representative examples taken directly from the source.
AppService Spec
The root service test verifies that Angular’s dependency injection correctly instantiatesAppService:
HomeComponent Spec
The home component test usesComponentFixture to compile the component and confirm it mounts without errors:
app.component.spec.ts, checkbox.component.spec.ts, and history.component.spec.ts all use TestBed + ComponentFixture to bootstrap each component in isolation.
Functional Test Cases
The test plan organizes functional cases into five modules. The table below reflects the status documented in the project’s test plan; AU-04 and REP-02 are backend-dependent or planned features — see the notes beneath each section.Authentication & Security
AU-01 — Valid Login
Input: Correct username and password
Expected: Successful access to the main dashboard
Expected: Successful access to the main dashboard
AU-02 — Invalid Login
Input: Wrong username or password
Expected: Error message displayed; no access granted
Expected: Error message displayed; no access granted
AU-03 — Logout
Input: Authenticated user clicks logout
Expected: Session cleared; redirect to
Expected: Session cleared; redirect to
/loginAU-04 — Account Lockout (Planned)
Input: 5 consecutive failed login attempts
Expected: Temporary account lock applied
Note: This is a backend requirement (Spring Boot). It is not implemented in the current Angular frontend source.
Expected: Temporary account lock applied
Note: This is a backend requirement (Spring Boot). It is not implemented in the current Angular frontend source.
Inventory Management
| ID | Test Case | Input | Expected Result |
|---|---|---|---|
| INV-01 | Add new product | Full product data | Product registered in the system |
| INV-02 | Modify existing product | Product ID + updated fields | Product record updated correctly |
| INV-03 | Delete product | Product ID | Product removed from the database |
| INV-04 | Query inventory with filter | Search filter criteria | Filtered product list returned |
Orders & Sales
| ID | Test Case | Input | Expected Result |
|---|---|---|---|
| PED-01 | Create new order | Order details and client data | Order registered correctly |
| PED-02 | Modify existing order | Order ID + new data | Order updated successfully |
| PED-03 | Cancel order | Order ID | Order deleted from the system |
| PED-04 | Generate invoice | Confirmed order | PDF generated with full sale details |
User Administration
| ID | Test Case | Input | Expected Result |
|---|---|---|---|
| USR-01 | Register new user | Complete user data | User registered in the system |
| USR-02 | Assign role to user | Existing user + new role | Role assigned correctly |
| USR-03 | Deactivate user | User ID | User account disabled in the system |
Reports & Data Analysis
| ID | Test Case | Input | Expected Result |
|---|---|---|---|
| REP-01 | Generate sales report | Date range | Report generated correctly |
| REP-02 | Export report to Excel | Report data | .xlsx file downloaded — Planned (RF08 is classified as “Ideal” in the project specification; PDF export via jspdf is the currently confirmed export format) |
Test Tooling Overview
The following tools are defined in the project’s test plan as recommended tools for each testing layer. Karma and Jasmine are the only tools confirmed as installed dependencies in the current repository.Postman
API testing. Each Spring Boot REST endpoint is validated for correct HTTP status codes, response shapes, and error handling under both valid and invalid inputs.
Selenium
Frontend automation (recommended). End-to-end browser flows — login, inventory edits, order creation — can be scripted and replayed against the running Angular app.
Apache JMeter
Performance testing (recommended). Load scenarios simulate up to 500 concurrent users to verify the 2-second response-time SLA defined in the non-functional requirements.
OWASP ZAP
Security scanning (recommended). Automated active scans detect SQL injection, XSS, and CSRF attack surfaces before each production release.
Test Types
Functional Tests
Functional Tests
Each module is exercised against its requirements specification. Testers verify that every user-facing action — adding a product, placing an order, generating an invoice — behaves exactly as the functional requirements describe, with no missing fields and no data corruption.
Integration Tests
Integration Tests
Integration tests confirm that the Angular frontend and Spring Boot backend communicate correctly over REST/JSON. The Angular frontend passes identity via body fields (such as
uuid_admin and uuid_cliente) rather than Authorization headers. These tests verify that the PostgreSQL schema matches the API’s expected payloads and that cascading operations (e.g., cancelling an order updates inventory stock) work end-to-end.Usability Tests
Usability Tests
Real-user sessions are observed to confirm that new operators can learn the system within 4 hours (RNF01) and that navigation between inventory, orders, and reports is intuitive without training prompts.
Security Tests
Security Tests
OWASP ZAP (recommended) performs automated active scans against a staging deployment. Penetration testers also manually probe authentication endpoints for token leakage, privilege escalation, and injection vectors.
Performance Tests
Performance Tests
JMeter (recommended) scenarios ramp up to 500 concurrent virtual users over a 10-minute window. Each simulated user authenticates, queries inventory, and creates an order. All server response times must remain below 2 seconds, and no errors may occur above a 0.1% threshold.
Acceptance Criteria
Critical Cases
100% of critical test cases (all AU, INV, PED, and USR cases) must pass before a build is approved for production deployment.
No High-Priority Blockers
Zero open blocker or critical severity defects are allowed at release. High-priority issues must be resolved and re-tested before sign-off.