Engineering-Nachweis

Bz Info ist nicht nur ein Portfolio. Es ist ein überprüfbares Produktsystem.

Diese Seite zeigt die technische Logik der Plattform: Web-Architektur, NestJS Backend, Qualität, Tests, Betrieb, SEO, i18n und Delivery-Disziplin.

Husky pre-pushESLint + Prettierportfolio-api/test9 quality phasesmodule runners.reports output

Generierte Seiten

714

Statische Seiten nach Expertise-, Tool- und Lokalisierungs-Erweiterungen.

Aktive Sprachen

Französisch, Englisch, Arabisch, Spanisch, Deutsch und Niederländisch mit eigenen Routen.

Qualitätskette

Typecheck + Build

Systematische Frontend-Validierung vor dem Festschreiben von Änderungen.

Backend quality is module-owned.

Each serious module can expose its own perf, contract, unit, integration, E2E, smoke, security and mutation phases.

Systemkarte

Eine Plattform, die als vollständiges Produkt gedacht ist.

Der Nachweis entsteht aus dem gesamten System: öffentliche Website, API, Admin, Dokumentation, Tools, lokalisierter Inhalt und Qualität.

01 · Visible

Public web

Next.js, localized routes, SEO, sitemap, expertise pages and documentation.

02 · Architecture

Backend API

NestJS API for contact, chatbot, analytics, communication and product workflows.

03 · Operations

Admin system

Future supervision for requests, conversations, logs, statistics and operations.

04 · Expansion

Tools lab

Developer packs, scripts, transactional SMS gateway and local AI workstation.

Backend-Nachweis

Das Backend wird als Produkt-Rückgrat behandelt.

Ziel ist es, Module, Verträge, Validierung, Domänenflüsse, Sicherheit und Integrationen strukturiert zu zeigen.

NestJS

Modular architecture

Modules, services, DTOs, guards, validation and maintainable API contracts.

Prisma

Controlled persistence

Models, transactions, constraints and clear separation between domain and storage.

Realtime

Live flows

Chat, support, notifications and admin interfaces connected to real system state.

Communication

Email, SMS and notifications

Transactional channels designed with limits, logs, security and precise usage.

HTTP request

Controller receives a public operation through a documented route.

DTO validation

class-validator, Swagger metadata and ValidationPipe must stay aligned.

Guard / auth

Access rules, JWT context, throttling and role checks protect the boundary.

Service decision

Business rules are isolated, testable and protected by explicit branches.

Prisma / storage

Transactions, constraints and persistence shape are verified by tests.

Reports

Schemathesis, smoke, ZAP, k6 and Stryker expose behavior from outside.

Backend-Methodik

Eine progressive Methode, die über Frameworks hinweg funktioniert.

NestJS, Spring Boot, Python, Go oder .NET: verstehen, absichern, verbessern, messen, härten und dokumentieren.

Reconnaissance

Routen, DTOs, Guards, Services, Datenzugriff, Fehler und öffentliche Verträge lesen.

Das System verstehen, bevor es geändert wird.

Leichtes Refactoring

Verantwortlichkeiten klären, ohne das Produkt neu zu schreiben.

Technische Schuld reduzieren, ohne riskante Migration.

Basistests

Bestehendes Verhalten mit einfachen, aber nützlichen Tests absichern.

Ein Sicherheitsnetz vor tieferen Korrekturen schaffen.

Tiefe Tests

Branches, Fehler, Grenzen, Transaktionen, null, undefined und Exceptions testen.

Blinde Flecken angreifen, die oberflächliche Tests übersehen.

Integration & E2E

Grenzen zwischen API, Auth, Datenbank und Services validieren.

Verhalten außerhalb der Isolation beweisen.

Performance

Latenz, Konkurrenz, DB-Contention, N+1, Throttling, Speicher und langsame Pfade messen.

Finden, was unter echter Last bricht.

Contract testing

OpenAPI und Schemathesis gegen reales Verhalten laufen lassen.

DTOs, Swagger, ValidationPipe und dokumentierte Antworten korrigieren.

Runtime security

Smoke Checks, ZAP, Logs und Runtime-Verifikation ergänzen.

Das System beobachten, wie es wirklich läuft.

Mutation testing

Coverage allein reicht nicht; Stryker misst die echte Assertionskraft.

portfolio-api/test

Module-by-module quality factory

Each backend module owns the same quality surface, from contract checks to mutation testing, with a dedicated global runner and local README.

01-perf

Load, latency and concurrency baseline.

02-schemathesis

OpenAPI contract attack against real endpoints.

03-unit

DTOs, services, guards, modules and branch decisions.

04-integration

Database, providers and cross-service boundaries.

05-e2e

Real API flows through the application surface.

06-smoke

Runtime availability and critical path sanity checks.

07-zap

Basic exposed security signals.

08-mutation

Stryker mutation strength and test robustness.

Sample modules already shaped with this convention

admin-authadmin-dashboardadmin-supportaudit-logschatchatbotcontacthealthleadsmonitoringnotifications

test/<module>/
├── 01-perf
├── 02-schemathesis
├── 03-unit
├── 04-integration
├── 05-e2e
├── 06-smoke
├── 07-zap
├── 08-mutation
├── scripts/run-<module>-global.sh
└── README.md

bash

Global module runner

One command can run the module quality chain with explicit toggles.

MODULE_NAME="admin-auth"RUN_ADMIN_AUTH_SCHEMATHESIS="${RUN_ADMIN_AUTH_SCHEMATHESIS:-true}"RUN_ADMIN_AUTH_SMOKE="${RUN_ADMIN_AUTH_SMOKE:-true}"RUN_ADMIN_AUTH_UNIT="${RUN_ADMIN_AUTH_UNIT:-true}"RUN_ADMIN_AUTH_INTEGRATION="${RUN_ADMIN_AUTH_INTEGRATION:-true}"RUN_ADMIN_AUTH_E2E="${RUN_ADMIN_AUTH_E2E:-true}"RUN_ADMIN_AUTH_MUTATION="${RUN_ADMIN_AUTH_MUTATION:-true}"

bash

Schemathesis contract attack

OpenAPI is fetched from the running API, then attacked in Docker.

SCHEMA_FETCH_URL="${SCHEMA_FETCH_URL:-http://localhost:4002/api/docs-json}"SCHEMATHESIS_BASE_URL="${SCHEMATHESIS_BASE_URL:-http://host.docker.internal:4002}"SCHEMATHESIS_PATH_REGEX="${SCHEMATHESIS_PATH_REGEX:-^/api/v1/admin/auth/(login|refresh|logout|me)$}"docker run --rm --add-host=host.docker.internal:host-gateway \  ghcr.io/schemathesis/schemathesis:stable run openapi-admin-auth.json

json

Stryker mutation gate

Mutation score is a hard quality threshold, not a vanity metric.

{  "testRunner": "jest",  "mutate": ["src/modules/admin-auth/**/*.ts"],  "coverageAnalysis": "perTest",  "thresholds": {    "high": 100,    "low": 100,    "break": 100  }}

javascript

k6 health baseline

Performance tests expose latency and failure-rate risks outside unit isolation.

export const options = {  thresholds: {    http_req_failed: ["rate<0.01"],    checks: ["rate>0.99"],    "http_req_duration{endpoint:health}": ["p(95)<250", "p(99)<500"],  },};

Werkzeug → Risiko

Jedes Werkzeug greift eine andere Risikokategorie an.

Qualität ist keine Logo-Sammlung. Jeder Schritt hat einen Grund und deckt einen eigenen Winkel ab.

TypeScript

Statische Fehler

Erkennt Typinkonsistenzen vor Runtime, besonders in DTOs, Services und Verträgen.

Unit tests

Fragile Fachlogik

Sichert Regeln, Branches, Fehler und isolierte Grenzfälle.

Integration tests

Unsichtbare Grenzen

Prüft Interaktionen zwischen Services, Transaktionen, Datenbank und Dependencies.

E2E tests

Unvollständige API-Flows

Validiert reale Flows vom Endpoint bis zum erwarteten Produktverhalten.

Last und Konkurrenz

Zeigt Latenz, Locks, N+1, Contention und Verhalten, das isolierte Tests nicht zeigen.

Schemathesis

Falscher OpenAPI-Vertrag

Findet Abweichungen zwischen Swagger, DTOs, ValidationPipe, HTTP-Status und Antworten.

ZAP

Offene Runtime-Fläche

Erkennt grundlegende Sicherheitssignale von außen.

Stryker

Schwache Tests

Beweist, ob die Testsuite Verhaltensmutationen erkennt.

Vertrauensmodell

Vertrauen wächst, wenn mehrere Risiken angegriffen werden.

Dieses Diagramm ist ein didaktisches Modell, keine wissenschaftliche Statistik.

Static

20%

Der Code kompiliert und offensichtliche Fehler sinken.

Unit

38%

Wichtige Fachentscheidungen werden abgesichert.

Integration

55%

Service/Datenbank/API-Grenzen werden sicherer.

E2E

68%

Reale Flows werden Ende-zu-Ende validiert.

Contract

80%

Der öffentliche Vertrag wird automatisch angegriffen.

Runtime

88%

Performance, Smoke und Runtime-Security ergänzen Realität.

Mutation

95%

Die Testsuite beweist, dass sie gefährliche Änderungen erkennt.

Quality Pipeline

Qualität ist eine Kette, keine Dekoration.

Jede Stufe reduziert eine Risikokategorie: Typisierung, Vertrag, Verhalten, Runtime, Sicherheit oder Testrobustheit.

Static confidence

Check typing, formatting, conventions and obvious errors before runtime.

TypeScriptESLintPrettierBuild

Behavior confidence

Test business decisions, integrations and end-to-end user paths.

UnitIntegrationE2ESmoke

Contract confidence

Attack API contracts and verify that documentation reflects real behavior.

OpenAPISchemathesisSwaggerDTO validation

Hardening confidence

Actively look for weaknesses instead of stopping at a green build.

StrykerZAPk6Audit logs

Was das beweist

Der Wert liegt in wiederholbarer Disziplin.

Diese Seite zeigt eine Methode: strukturieren, prüfen, dokumentieren, lokalisieren, messen und refaktorieren.

Readable architecture

Pages, content, components and routes are separated to stay maintainable.

Real refactoring

Oversized files are split instead of being accepted as silent debt.

Verifiable SEO

Sitemap, canonical, hreflang and localized routes are treated as public contracts.

Proof through product

The site itself demonstrates the expected level: content, UI, architecture and validation.

Nutzbarer Nachweis

Ein technisches Gespräch kann mit konkreten Beweisen beginnen.

Für Backend-Missionen, technische Recovery oder Produktplattformen dient diese Seite als technischer Einstieg.

Anfrage besprechen Dokumentation ansehen