Skip to main content

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.

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.

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 in package.json alongside Chrome Launcher (for headless browser execution), a coverage reporter, and an HTML reporter.
PackageVersion
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

1

Install dependencies

Make sure all packages are installed before running tests:
npm install
2

Run all unit tests

Execute the full Jasmine test suite via the Angular CLI script defined in package.json:
ng test
Karma launches a Chrome instance, runs every .spec.ts file it finds, and streams pass/fail results to the terminal.
3

Run tests with coverage

To generate an HTML coverage report under coverage/:
ng test --code-coverage
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 instantiates AppService:
import { TestBed } from '@angular/core/testing';
import { AppService } from './app.service';

describe('AppService', () => {
  let service: AppService;

  beforeEach(() => {
    TestBed.configureTestingModule({});
    service = TestBed.inject(AppService);
  });

  it('should be created', () => {
    expect(service).toBeTruthy();
  });
});

HomeComponent Spec

The home component test uses ComponentFixture to compile the component and confirm it mounts without errors:
import { ComponentFixture, TestBed } from '@angular/core/testing';
import { HomeComponent } from './home.component';

describe('HomeComponent', () => {
  let component: HomeComponent;
  let fixture: ComponentFixture<HomeComponent>;

  beforeEach(async () => {
    await TestBed.configureTestingModule({
      declarations: [HomeComponent]
    }).compileComponents();

    fixture = TestBed.createComponent(HomeComponent);
    component = fixture.componentInstance;
    fixture.detectChanges();
  });

  it('should create', () => {
    expect(component).toBeTruthy();
  });
});
Other spec files in the project follow the same pattern: 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

AU-02 — Invalid Login

Input: Wrong username or password
Expected: Error message displayed; no access granted

AU-03 — Logout

Input: Authenticated user clicks logout
Expected: Session cleared; redirect to /login

AU-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.

Inventory Management

IDTest CaseInputExpected Result
INV-01Add new productFull product dataProduct registered in the system
INV-02Modify existing productProduct ID + updated fieldsProduct record updated correctly
INV-03Delete productProduct IDProduct removed from the database
INV-04Query inventory with filterSearch filter criteriaFiltered product list returned

Orders & Sales

IDTest CaseInputExpected Result
PED-01Create new orderOrder details and client dataOrder registered correctly
PED-02Modify existing orderOrder ID + new dataOrder updated successfully
PED-03Cancel orderOrder IDOrder deleted from the system
PED-04Generate invoiceConfirmed orderPDF generated with full sale details

User Administration

IDTest CaseInputExpected Result
USR-01Register new userComplete user dataUser registered in the system
USR-02Assign role to userExisting user + new roleRole assigned correctly
USR-03Deactivate userUser IDUser account disabled in the system

Reports & Data Analysis

IDTest CaseInputExpected Result
REP-01Generate sales reportDate rangeReport generated correctly
REP-02Export report to ExcelReport 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

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 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.
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.
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.
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.
Integrate ng test --watch=false --code-coverage into your CI pipeline (GitHub Actions, GitLab CI, or Cloud Build) so every pull request automatically blocks merge if unit tests regress or coverage drops below the established threshold.

Build docs developers (and LLMs) love