DEV Community: Vincent Davis

Beyond Unit Tests: Implementing BDD and Penetration Testing in GBIM

Vincent Davis — Mon, 11 May 2026 09:43:49 +0000

IR Part A #4 - More Testing: Stress Testing, Penetration Testing, Security Testing, and BDD

Prepared on: May 11, 2026

Project scope: BE-GBM and fe-gbm

Feature scope: account registration, account activation, login lockout, admin approval/rejection of submissions, and non-admin access control.

Claim Summary

This claim demonstrates that the GBM project has implemented advanced testing in four areas required by the IR B5 rubric: security testing, penetration testing, behavior-driven development, and stress testing.

Security Testing

Tools and approach: GitLab SAST, Dependency Scanning, Secret Detection, and OWASP ZAP baseline.

Primary evidence: the FE security pipeline passed, the BE security analyzer jobs passed in MR pipeline 279225, and the ZAP baseline job is available for staging or scheduled execution.

Penetration Testing

Tools and approach: OWASP-mapped abuse-case tests.

Primary evidence: 8 concrete abuse paths cover login, registration, activation tokens, authorization, mass assignment, and email enumeration.

BDD

Tools and approach: Behave Django and Playwright BDD.

Primary evidence: BE has 3 features, 12 scenarios, and 57 steps passed. FE has 3 Playwright BDD tests discovered, and e2e-bdd passed in CI.

Stress Testing

Tools and approach: Locust.

Primary evidence: registration burst, authenticated activity, quality-assurance, and admin dashboard workloads are modeled as manual headless runs with HTML/CSV output.

The strongest evidence is executable and measurable: backend BDD passes, backend regression subset passes, frontend BDD/security pipeline passes, and backend security analyzer jobs pass. Stress testing is intentionally treated as manual evidence rather than a merge-request gate because staging capacity, credentials, seed data, rate limits, and email side effects can make performance numbers non-deterministic.

Screenshot Evidence

Only non-trivial evidence needs screenshots. Commit links, command snippets, and static documentation paths are already explicit in text and do not need images.

1. Backend MR Pipeline

2. Frontend MR Pipeline

3. Behave Results

https://gitlab.cs.ui.ac.id/ppl-fasilkom-ui/2026/kelas-d/group1-gb/be-gbm/-/jobs/802493

4. integrated testing with CI/CD

Merge Requests and Commit Links

Merge Requests

Repo	Merge Request
Backend	https://gitlab.cs.ui.ac.id/ppl-fasilkom-ui/2026/kelas-d/group1-gb/be-gbm/-/merge_requests/157
Frontend	https://gitlab.cs.ui.ac.id/ppl-fasilkom-ui/2026/kelas-d/group1-gb/fe-gbm/-/merge_requests/141

Backend Commits Used as Evidence

Commit	Evidence Contribution
https://gitlab.cs.ui.ac.id/ppl-fasilkom-ui/2026/kelas-d/group1-gb/be-gbm/-/commit/64046e3c70e2ad419d14fc5580863821641991a0	Adds the backend IR B5 testing baseline: security templates, BDD features, load-test documentation, and evidence structure.
https://gitlab.cs.ui.ac.id/ppl-fasilkom-ui/2026/kelas-d/group1-gb/be-gbm/-/commit/8b75a9ed85b67ffc1e920a1bb842ca4503c4d684	Adds executable backend BDD and penetration-testing scenarios against real DRF endpoints.
https://gitlab.cs.ui.ac.id/ppl-fasilkom-ui/2026/kelas-d/group1-gb/be-gbm/-/commit/f9f62adb791fd5af38cc70d93bdbb0eb6ac7c62f	Adds `behave` and `behave-django` to `requirements.txt` so BDD can run consistently in the Django environment.
https://gitlab.cs.ui.ac.id/ppl-fasilkom-ui/2026/kelas-d/group1-gb/be-gbm/-/commit/eb07e5e2a224a563605238c20fa33526a3c85e34	Enables backend security analyzer execution in the MR pipeline.
https://gitlab.cs.ui.ac.id/ppl-fasilkom-ui/2026/kelas-d/group1-gb/be-gbm/-/commit/dd64fdf164e2bbfbf36860d9caf819fbccf37341	Finalizes backend CI and stress-testing policy: deterministic MR checks remain in CI, while stress evidence is documented through Locust manual runs.

Frontend Commits Used as Evidence

Commit	Evidence Contribution
https://gitlab.cs.ui.ac.id/ppl-fasilkom-ui/2026/kelas-d/group1-gb/fe-gbm/-/commit/fff3cb1fcb7556b31399781888d90e6de15bbab8	Adds frontend IR B5 security templates and Playwright BDD structure.
https://gitlab.cs.ui.ac.id/ppl-fasilkom-ui/2026/kelas-d/group1-gb/fe-gbm/-/commit/dd62510177af54d760b7759299ee43df00282222	Implements API-backed frontend BDD flows for registration and admin submission behavior.
https://gitlab.cs.ui.ac.id/ppl-fasilkom-ui/2026/kelas-d/group1-gb/fe-gbm/-/commit/1e5beadbca00a422b05922935af6248ce25ea874	Enables frontend MR pipeline execution for security analyzers, BDD generation/discovery, and quality checks.

Execution Evidence

Backend Evidence

Check	Command or Source	Result
Dependency installation	`.\.venv\Scripts\python.exe -m pip install -r requirements.txt`	`behave==1.2.6` and `behave-django==1.4.0` available in `BE-GBM\.venv`.
Django system check	`.\.venv\Scripts\python.exe manage.py check`	`System check identified no issues`.
Behave BDD	`.\.venv\Scripts\python.exe manage.py behave --simple --junit --junit-directory=bdd-reports`	3 features passed, 12 scenarios passed, 57 steps passed, 0 failed.
Regression subset	`.\.venv\Scripts\python.exe manage.py test authentication.tests.test_register_view authentication.tests.test_activation_views pengajuan.tests.test_views_admin`	65 tests passed.
Locust package	`.\.venv\Scripts\locust.exe --version`	`locust 2.43.4`.
GitLab CI lint	GitLab `/ci/lint` API with merged YAML	`valid=True`, `warnings=[]`.
Staging register baseline	`curl.exe -m 75 -w` to `POST /api/auth/register/`	HTTP 202 in 5.134493s.

Backend MR Pipeline 279225 Evidence

Pipeline: https://gitlab.cs.ui.ac.id/ppl-fasilkom-ui/2026/kelas-d/group1-gb/be-gbm/-/pipelines/279225

Job	Status	Why It Matters
`test`	success	Confirms the standard backend regression test suite still passes.
`bdd`	success	Confirms the executable BDD scenarios are runnable in CI.
`diff_coverage`	success	Confirms changed-code coverage requirements are enforced.
`semgrep-sast`	success	Confirms backend SAST analyzer runs in the MR pipeline.
`gemnasium-python-dependency_scanning`	success	Confirms Python dependency scanning runs in the MR pipeline.
`secret_detection`	success	Confirms committed secrets are scanned in the MR pipeline.
`debug-mr-analyzer`	success	Confirms the existing project diagnostic job still completes.
`sonarqube`	failed	Not used as evidence for this claim; the security, BDD, test, and coverage evidence above are the concrete data used here.

Frontend Evidence

Frontend pipeline: https://gitlab.cs.ui.ac.id/ppl-fasilkom-ui/2026/kelas-d/group1-gb/fe-gbm/-/pipelines/279116

Check	Evidence
GitLab CI lint	`valid=True`, `warnings=[]` for merged YAML.
BDD generation	`npm run e2e:bdd:gen` succeeded.
Playwright test discovery	`npx playwright test --list` found 3 tests across 2 generated spec files.
Targeted ESLint	`npx eslint e2e/steps/common.steps.ts playwright.config.ts` succeeded.
CI jobs	`test`, `e2e-bdd`, `diff_coverage`, `semgrep-sast`, `gemnasium-dependency_scanning`, `secret_detection`, and `sonarqube` succeeded.

Demonstration of Advanced Testing Tools

Security Testing

Security testing is implemented through GitLab security templates and an OWASP ZAP baseline job.

Tool	Where It Runs	Evidence
GitLab SAST	FE and BE MR pipelines	FE `semgrep-sast` success in pipeline 279116; BE `semgrep-sast` success in pipeline 279225.
Dependency Scanning	FE and BE MR pipelines	FE `gemnasium-dependency_scanning` success; BE `gemnasium-python-dependency_scanning` success.
Secret Detection	FE and BE MR pipelines	FE and BE `secret_detection` success.
OWASP ZAP Baseline	BE scheduled/staging-capable job	`dast-zap-baseline` stores `zap-report.html` and `zap-report.json` artifacts when executed.

Project benefit: security checks are no longer an informal review activity only. They are reproducible CI jobs and are complemented by executable abuse-case tests for the authentication and authorization paths that matter most to GBM.

Penetration Testing

The penetration-testing evidence is implemented as abuse-case integration tests. This is intentionally more concrete than a manual checklist because every abuse path has an endpoint, an expected response, and a regression signal.

#	Risk	Endpoint or Flow	Expected Result	Evidence
1	Broken Access Control	`PATCH /api/pengajuan/admin/<uuid>/status/` as non-admin	403 Forbidden	BDD scenario returns 403.
2	Identification and Authentication Failure	Repeated wrong-password login	429 lockout	BDD login lockout scenario returns 429.
3	Insecure Design / Brute Force	Repeated registration attempts	429 rate limit	BDD registration burst scenario returns 429.
4	Mass Assignment	Register with `role=ADMIN` and superuser-like fields	400 rejection and no forged admin	BDD scenario asserts no forged admin account exists.
5	Token Tampering	Activation with modified token	400 `TOKEN_INVALID`	BDD activation scenario returns `TOKEN_INVALID`.
6	Token Expiry	Activation with expired token	400 `TOKEN_EXPIRED`	BDD activation scenario returns `TOKEN_EXPIRED`.
7	Email Enumeration	Duplicate registration	Generic 202 response	BDD scenario verifies no duplicate/existing wording leaks account existence.
8	Invalid Admin State Transition	Admin rejects/approves invalid status transition	400 validation failure	BDD admin scenario verifies invalid transition rejection.

Project benefit: these tests cover attacker behavior, not only happy-path behavior. They protect the project from regressions where a normal feature change accidentally weakens authorization, throttling, token validation, or privacy-preserving registration responses.

BDD

BDD is used as executable specification for critical business behavior.

Layer	Tool	Scope	Evidence
Backend	Behave Django	Registration, duplicate email behavior, activation token validity, login lockout, admin authorization, approve/reject transitions	3 features, 12 scenarios, 57 steps passed.
Frontend	Playwright BDD	User-visible registration and admin submission flows backed by API setup	3 generated Playwright BDD tests discovered; `e2e-bdd` passed in CI.

Project benefit: reviewers can read behavior in Gherkin while the CI/local commands verify the same behavior against real code paths. This reduces the gap between documentation, acceptance criteria, and regression tests.

Stress Testing

Stress testing is implemented with Locust because it models user behavior as Python HttpUser classes and can be run headlessly with CSV/HTML artifacts.

Locust User	Behavior Modeled	Authentication Need	Expected Output
`RegistrationBurstUser`	High-volume semester-start registration	No login required because registration is public	Request rate, failure rate, latency percentiles, HTML/CSV report.
`AdminDashboardUser`	Admin login, pending submission listing, optional status update	Requires `LOCUST_ADMIN_EMAIL` and `LOCUST_ADMIN_PASSWORD`; optional `LOCUST_ADMIN_PENGAJUAN_ID` is a pending submission UUID, not an admin user id	Authenticated admin endpoint latency and failure report.
`KegiatanStressTestUser`	Authenticated kegiatan/statistik/periode access	Requires one or more user credentials through `LOCUST_EMAIL`/`LOCUST_PASSWORD` or numbered credential variables	Authenticated API stress profile.
`GBMQualityAssuranceUser`	Mixed endpoint profile across major backend API paths	Requires authenticated user credentials	Cross-endpoint baseline load profile.

Example commands:

python -m locust -f locustfile.py RegistrationBurstUser --host https://gbim-staging.ppl.cs.ui.ac.id --headless -u 50 -r 10 --run-time 2m --csv locust_register --html locust_register.html
python -m locust -f locustfile.py AdminDashboardUser --host https://gbim-staging.ppl.cs.ui.ac.id --headless -u 20 -r 5 --run-time 2m --csv locust_admin --html locust_admin.html
python -m locust -f locustfile.py KegiatanStressTestUser --host https://gbim-staging.ppl.cs.ui.ac.id --headless -u 20 -r 5 --run-time 2m --csv locust_kegiatan --html locust_kegiatan.html

Claim boundary: this blog does not claim that staging meets p95 below 500ms. The measurable claim is that stress-test workloads are defined using realistic user behavior, can be executed manually, produce machine-readable CSV plus reviewable HTML reports, and correctly separate expected protection responses from unexpected failures.

Measurable Project Benefits

This section compares the project before IR B5 More Testing with the final implemented state.

Before IR B5 More Testing	After Final Implementation	Concrete Data
Critical registration, activation, and admin behavior was not documented as one executable specification for this claim.	Backend and frontend BDD now describe the critical journeys in Gherkin and execute them against real application behavior.	BE: 3 features, 12 scenarios, 57 steps passed. FE: 3 Playwright BDD tests discovered and `e2e-bdd` passed.
Security testing evidence was not consolidated into repeatable MR-level analyzer jobs plus explicit abuse-case scenarios.	GitLab security analyzers run in CI, while abuse cases verify access control, throttling, token validity, and mass-assignment protection.	FE pipeline 279116 security jobs passed. BE pipeline 279225 `semgrep-sast`, `gemnasium-python-dependency_scanning`, and `secret_detection` passed.
Penetration-testing evidence was not mapped from risks to endpoints, expected statuses, and regression checks.	8 OWASP-mapped abuse paths now specify the endpoint/flow, expected result, and executable evidence.	403 for non-admin access, 429 for lockout/rate-limit, 400 for invalid/tampered token paths, generic 202 for duplicate registration.
Duplicate registration behavior was not presented as privacy/security evidence for this claim.	Duplicate email registration now has an explicit BDD assertion that the response remains generic and does not leak account existence.	Scenario `Duplicate email registration does not leak account existence` returns 202 and checks response wording.
Activation-token abuse behavior was not presented as a complete negative-path evidence set.	Invalid and expired activation token paths are explicitly tested.	BDD verifies `TOKEN_INVALID` and `TOKEN_EXPIRED`.
Frontend testing evidence did not show API-backed BDD plus security scanning in one MR pipeline.	The FE MR pipeline runs unit/quality jobs, BDD generation/discovery, and security analyzers.	Pipeline 279116: `test`, `e2e-bdd`, `diff_coverage`, `sonarqube`, SAST, dependency scanning, and secret detection succeeded.
Stress testing was not expressed as named user workloads tied to GBM roles and endpoints.	Locust now models registration burst, admin dashboard, authenticated kegiatan, and mixed QA workloads.	`locustfile.py` defines `RegistrationBurstUser`, `AdminDashboardUser`, `KegiatanStressTestUser`, and `GBMQualityAssuranceUser`.
Rate limiting could be misread as a failure in high-load or abuse scenarios.	Expected protection is distinguished from unexpected failure.	BDD expects 429 in abuse/rate-limit cases; Locust treats 202 and 429 as acceptable for registration burst.

Literature and Best Practices

The implementation follows current industry guidance by turning general testing advice into concrete project controls.

Reference	Best-Practice Principle	Project Application	Correlating Evidence
OWASP Top 10 2021	Web applications should explicitly test risks such as broken access control, insecure design, identification/authentication failures, and software/data integrity failures.	Abuse cases target non-admin access, login lockout, registration throttling, token tampering/expiry, and mass assignment.	BDD scenarios return 403, 429, 400, `TOKEN_INVALID`, `TOKEN_EXPIRED`, and generic 202 as expected.
OWASP ASVS	Security verification should be expressed as testable technical controls, not only policy statements.	Authentication, token lifecycle, authorization, and privacy-preserving registration behavior are verified as executable tests.	Backend BDD: 12 scenarios and 57 steps passed.
OWASP Web Security Testing Guide	Security testing should include misuse and invalid-use cases that reveal enumeration, weak defenses, and abuse of valid functionality.	Duplicate registration, brute-force login, register burst, invalid token, expired token, and non-admin admin requests are tested directly.	8 abuse paths in the penetration-testing evidence.
OWASP Abuse Case Cheat Sheet	Abuse cases help convert attacker goals into concrete requirements and tests.	The project defines attacker-style behaviors such as forged admin registration, token tampering, duplicate email enumeration, and unauthorized admin status changes.	`pen-test-report.md` and BDD feature files map abuse behavior to expected API responses.
GitLab Application Security	Security scanning should be integrated into the development workflow so findings are repeatable and visible during merge requests.	SAST, dependency scanning, and secret detection are configured in FE and BE CI.	FE pipeline 279116 and BE pipeline 279225 security analyzer jobs succeeded.
OWASP ZAP Baseline Scan	Passive DAST scanning is suitable for a safe baseline assessment of deployed/staging web applications.	The backend CI includes a `dast-zap-baseline` job that produces HTML/JSON artifacts when run against staging.	`.gitlab-ci.yml` defines `zap-report.html` and `zap-report.json` artifacts.
Cucumber / Gherkin BDD	Requirements should be readable as executable specifications that validate actual software behavior.	Registration, activation, and admin flows are written as Gherkin features and executed through Behave/Playwright.	BE 3 features passed; FE BDD generation and discovery succeeded.
Playwright Test Isolation	Browser contexts isolate state so tests do not leak cookies/session data into each other.	FE BDD uses isolated browser/page state and API-backed setup for role-specific flows.	3 Playwright BDD tests discovered and CI `e2e-bdd` succeeded.
Locust Documentation	Load tests should model user behavior with tasks, wait time, headless execution, and exportable statistics.	Locust users model registration, admin dashboard, kegiatan, and QA workloads; commands produce CSV and HTML reports.	`locustfile.py` uses `HttpUser`, `@task`, `between`, `on_start`, `--headless`, `--csv`, and `--html`.
Martin Fowler's Practical Test Pyramid	A healthy test strategy keeps many lower-level tests while adding only targeted end-to-end/BDD tests for high-value flows.	IR B5 does not replace existing unit/API tests; it adds focused BDD and security scenarios for critical journeys.	65 backend regression tests passed in addition to 12 BDD scenarios.

Why These References Matter for GBM

The references are not used as generic citations only. Each one changes how testing is applied in this project:

OWASP Top 10, ASVS, WSTG, and Abuse Case guidance shift testing from happy-path verification to attacker-aware verification.
GitLab Application Security shifts security testing from occasional manual review to repeatable MR evidence.
Cucumber/Gherkin shifts business-critical behavior from scattered implementation knowledge to readable executable specifications.
Playwright isolation prevents frontend BDD from becoming flaky due to leaked session state between admin and non-admin flows.
Locust keeps stress testing realistic by modeling user roles and wait times instead of sending context-free requests.
The Test Pyramid keeps the suite economically sane: unit/API tests remain broad, while BDD/E2E tests are targeted to the highest-risk workflows.

References:

OWASP Top 10 2021: https://owasp.org/Top10/2021/
OWASP ASVS: https://owasp.org/www-project-application-security-verification-standard/
OWASP Web Security Testing Guide, application misuse testing: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/10-Business_Logic_Testing/07-Test_Defenses_Against_Application_Misuse
OWASP Abuse Case Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Abuse_Case_Cheat_Sheet.html
GitLab SAST: https://docs.gitlab.com/ee/user/application_security/sast/
GitLab Application Security detection: https://docs.gitlab.com/user/application_security/detect/
OWASP ZAP Baseline Scan: https://www.zaproxy.org/docs/docker/baseline-scan/
Cucumber BDD overview: https://cucumber.io/docs/guides/overview/
Playwright test isolation: https://playwright.dev/docs/browser-contexts
Locust documentation: https://docs.locust.io/en/stable/
Locust configuration and report options: https://docs.locust.io/en/stable/configuration.html
Martin Fowler, Practical Test Pyramid: https://martinfowler.com/articles/practical-test-pyramid.html

Critique of Previous Testing and Quality Improvements

This critique compares the condition before IR B5 More Testing existed with the final implemented state.

Critique 1: Critical flows were not represented as consolidated executable specifications

Before IR B5, critical behavior such as registration, activation, login lockout, and admin approval was not presented as one readable executable specification for reviewers. The risk was not that the project had no tests at all; the risk was that the business-critical acceptance behavior was spread across implementation-level tests and was harder to review as user journeys.

Final improvement: backend and frontend BDD now describe those journeys in Gherkin and execute them against real system behavior.

Evidence:

Backend Behave: 3 features, 12 scenarios, 57 steps passed.
Frontend Playwright BDD: 3 tests discovered; e2e-bdd passed in pipeline 279116.

Critique 2: Security behavior was not presented as explicit abuse-case coverage

Before IR B5, the security posture for this claim was not organized around attacker behavior. A reviewer could not quickly trace OWASP risks to endpoint-level expected responses.

Final improvement: the penetration-testing evidence now maps attacker-style actions to concrete API behavior: non-admin access is rejected, lockout/rate limit is enforced, forged admin registration is rejected, tampered/expired tokens fail safely, and duplicate registration avoids account enumeration.

Evidence:

8 abuse paths documented and implemented.
Expected responses include 403, 429, 400, TOKEN_INVALID, TOKEN_EXPIRED, and generic 202.

Critique 3: Security scanning was not consistently demonstrated as MR evidence for both FE and BE

Before IR B5, security evidence was not presented as a complete MR-level story across frontend and backend.

Final improvement: FE and BE now both show CI-level security analyzer execution. FE pipeline 279116 passed the security jobs, while BE pipeline 279225 passed SAST, dependency scanning, and secret detection.

Evidence:

FE pipeline 279116: semgrep-sast, gemnasium-dependency_scanning, and secret_detection success.
BE pipeline 279225: semgrep-sast, gemnasium-python-dependency_scanning, and secret_detection success.

Critique 4: Stress testing was not tied to realistic GBM user behavior

Before IR B5, stress testing evidence was not expressed as clear GBM user workloads tied to roles, endpoints, and operational scenarios.

Final improvement: Locust now defines named workloads for semester-start registration, admin dashboard usage, authenticated kegiatan access, and mixed QA behavior.

Evidence:

RegistrationBurstUser models public registration load.
AdminDashboardUser models authenticated admin behavior.
KegiatanStressTestUser models authenticated kegiatan/statistik/periode access.
GBMQualityAssuranceUser models a mixed backend API baseline.

Critique 5: Expected protection responses needed to be separated from real failures

Before IR B5, high-load and abuse-case evidence could be misunderstood if every 429 response was treated as a failure. In this project, 429 can be the correct result because it means the rate limiter is protecting authentication or registration endpoints.

Final improvement: BDD and Locust distinguish expected protection from unexpected failure.

Evidence:

BDD expects 429 for login lockout and register burst controls.
RegistrationBurstUser treats 202 and 429 as acceptable outcomes for registration burst behavior.

Claim Boundaries

This blog deliberately does not claim the following:

It does not claim that staging stress testing meets p95 below 500ms.
It does not claim that stress tests should block every merge request.
It does not claim that BDD replaces unit/API tests.
It does not claim that security scanners prove the application has no vulnerabilities.

The actual claim is narrower and evidence-based: advanced testing tools are implemented, their outputs are understood, and their benefits are tied to concrete project data.

Conclusion

The IR B5 More Testing claim is satisfied because:

Advanced tools are implemented and used: Behave, Playwright BDD, GitLab SAST, Dependency Scanning, Secret Detection, OWASP ZAP baseline, and Locust.
The outputs are understood: 403 means access control is enforced, 429 means expected protection under abuse/load, 400 with token-specific codes means invalid activation is rejected safely, and security analyzer jobs provide repeatable MR evidence.
The benefits are measurable: 12 backend BDD scenarios passed, 65 backend regression tests passed, frontend pipeline 279116 passed BDD/security/quality checks, and backend pipeline 279225 passed test, BDD, coverage, and security analyzer jobs.
The work aligns with literature and current best practices: OWASP for abuse/security testing, GitLab for repeatable DevSecOps scanning, Cucumber for executable specifications, Playwright for isolated browser tests, Locust for user-behavior load modeling, and the Test Pyramid for balanced test economics.
The critique is based on the project state before IR B5 implementation and the final state after implementation.

Optimizing Test Design Mutation Testing, ISP, and CFG in the GBIM Project

Vincent Davis — Mon, 11 May 2026 07:12:12 +0000

Vincent Davis Leonard

TL;DR

I applied three test design optimization techniques (Input Space Partitioning or ISP, Control Flow Graph or CFG Analysis, and Mutation Testing) to the four main features I manage in the GBIM project. These features include account registration, account activation via token, account verification by admin, and the approval or rejection of submissions. The results include 33 new tests in the backend, 3 commits in the frontend, an expanded mutation scope, and the addition of Stryker threshold enforcement to the CI pipeline.

Tools and Methods Used

1. Input Space Partitioning (ISP)

ISP (Ammann & Offutt, Introduction to Software Testing, 2016) is a technique that divides the input domain of a function into equivalence classes. These classes are groups of values expected to be treated similarly by the system. Instead of trying all combinations, we select one representative value per partition.

I used the base-choice coverage strategy. We choose one valid value as a baseline and then vary one characteristic per test. This approach is efficient without falling into combinatorial explosion.

Tools used

Manual analysis of the source code (authentication/serializers.py, RegisterForm.tsx)
Annotation # ISP <characteristic>.<partition> in each test for traceability

Examples of partitioned characteristics for the Register feature

Characteristic	Partition
Email	valid, no `@`, active duplicate, inactive duplicate, >254 char, whitespace
Password	<8 char, exactly 8 without digits, no uppercase, valid strong
Role	`KAPRODI`, `GURU_BESAR`, `ADMIN` (blocked), invalid enum
Activation Token	valid fresh, expired, already used, malformed, missing

2. Control Flow Graph (CFG) Analysis

CFG (Ammann & Offutt, ch.7) represents the program execution flow as a graph where each node is a basic block and each edge is a conditional branch. From the CFG we identify prime paths which are the shortest non-repeating paths through all nodes.

Target module _validate_transition (pengajuan/services.py 66-75)

The actual code

66: def _validate_transition(self, previous_status: str, new_status: str) -> None:
67:     if (previous_status, new_status) not in ALLOWED_TRANSITIONS:
68:         raise ValidationError(
69:             {
70:                 "status": (
71:                     f"Transisi status dari '{previous_status}' ke '{new_status}' "
72:                     "tidak diperbolehkan."
73:                 )
74:             }
75:         )

The CFG of this code (node = line of code, edge = execution flow)

Prime paths

Path	Condition	Test
1→2→3→5	transition is not in `ALLOWED_TRANSITIONS`	`test_disetujui_to_menunggu_raises`, `test_menunggu_to_menunggu_raises`, etc
1→2→4→5	transition is in `ALLOWED_TRANSITIONS`	`test_menunggu_to_disetujui`, `test_menunggu_to_ditolak`, etc

This state machine CFG has 4 legal transitions and 5+ illegal transitions that all must have tests.

Tools

Manual source code analysis + Mermaid diagram (planned in the cfg/ folder)
Annotation # CFG: from_state→to_state in the tests

3. Mutation Testing

Mutation testing (Jia & Harman, IEEE TSE 2011) measures the quality of a test suite by injecting small defects or mutants into the source code. Examples include changing > to >=, or removing a condition. The process then checks if the test suite detects it (meaning the mutant is "killed"). The mutation score is calculated by dividing the killed mutants by the total mutants.

Tools

Backend mutmut (Python) with operators including AOR, LCR, ROR, and statement deletion
Frontend Stryker Mutator (JS/TS) with operators including arithmetic, logical, equality, string, and array

Both tools are complementary. The mutmut tool is more aggressive in statement deletion, while Stryker is richer in JS/TS level operators.

Application to the Project and Evidence of Improvement

ISP Application

Before this sprint, the test_register_serializers.py test only covered the happy path and one or two errors. After the ISP audit, the following changes were made.

New backend tests added

File	New Partitions	Count
`test_register_serializers.py`	email whitespace, email >254 char, inactive duplicate email, password exactly 8, password no digit, password no uppercase, password whitespace, role ADMIN blocked, role null, telephone invalid format	13
`test_activation_views.py`	token malformed, account already active	2
`test_views_admin_account_verification.py`	filter role invalid enum, filter status invalid enum, search no match, pagination beyond max	4
`test_views_admin_account_verification_detail.py`	approve AKTIF (idempotent), approve DITOLAK (reactivation), reject DITOLAK, reject non-existent, unauthorized non-admin	9

New frontend tests added

File	New Partitions
`RegisterForm.test.tsx`	API 429 rate limit response (ISP ApiError.status.429)
`useUpdateStatusPengajuan.test.ts`	MENUNGGU to DITOLAK transition (CFG happy-path DITOLAK)

CFG Application

Previously, StatusChangeService._validate_transition was only tested for 2 to 3 legal transitions. After the CFG analysis, I added tests for all 5 illegal transitions.

# CFG MENUNGGU to MENUNGGU (illegal self-loop)
def test_validate_transition_menunggu_to_menunggu_raises(self):
    ...

# CFG DISETUJUI to MENUNGGU (illegal backward)
def test_validate_transition_disetujui_to_menunggu_raises(self):
    ...

A total of 5 new CFG tests for illegal transitions were added along with annotations on the existing tests.

mutmut Scope Expansion

Previously, the pyproject.toml file only mutated pengajuan/views/ and kegiatan/views/. Now it includes the following paths.

paths_to_mutate = [
    "pengajuan/views/views_admin.py",
    "pengajuan/views/views_kaprodi.py",
    "kegiatan/views/views_kegiatan.py",
    "statistik_prodi/views.py",
    "authentication/serializers.py",   # new addition
    "authentication/services.py",      # new addition
    "authentication/views.py",         # new addition
    "pengajuan/services.py",           # new addition
    "pengajuan/serializers.py",        # new addition
]

Stryker Threshold Enforcement

The following configuration was added to stryker.config.mjs.

thresholds { high: 80, low: 70, break: 70 }

This means the frontend CI pipeline will automatically fail if the mutation score drops below 70 percent. This ensures the test quality does not regress.

Benefits, Concrete Data, and Best Practices

Quantitative Data

Metric	Before	After
Number of BE tests (auth and pengajuan scope)	~26 tests in target files	+33 = ~59 tests
Number of FE tests (3 target files)	97 tests	+2 = 99 tests
mutmut scope (paths_to_mutate)	4 paths (views only)	9 paths (views, services, serializers)
Stryker threshold FE	none	break 70, high 80
Documented ISP partitions (BE)	~5 (implicit)	28 explicit and annotated
CFG paths covered (StatusChangeService)	2 to 3 legal	4 legal and 5 illegal

Connection to Literature

ISP by Ammann & Offutt (2016)
Ammann and Offutt define Input Space Partitioning as the division of an input domain into partitions where each must be represented by at least one test. The base-choice coverage strategy I used is their recommendation for balancing coverage with efficiency.

Mutation Testing by Jia & Harman (2011)
The survey by Jia and Harman shows that the mutation score is a more reliable predictor of test suite quality than statement coverage. They also documented that equivalent mutants (mutants that are semantically identical to the original code) are a major challenge. I document these cases when found.

Petrović & Ivanković (ICSE 2021) on Mutation Testing
This paper reports the results of deploying mutation testing at scale at Google. Developers who receive mutation testing feedback consistently write better tests. The Stryker threshold I implemented follows this principle by maintaining the mutation score as an automatic quality gate.

Meszaros, xUnit Test Patterns (2007)
Test smells such as Assertion Roulette (multiple assertions without messages) and Obscure Test (tests that are difficult to understand) are anti-patterns I avoid. Every new test has one clear assertion and an ISP or CFG comment.

Google Testing Blog on Mutation Testing at Google (2018)
Google recommends focusing on killed mutants per time rather than the raw mutation score. This means prioritizing mutants in frequently changing code, which aligns with the auth and pengajuan features in this sprint.

Best Practices Followed

Each-choice minimum with base-choice for crucial parameters (Ammann & Offutt recommendation)
Mutation score as a quality gate rather than an optional metric (Google engineering practice)
Test isolation via override_settings and locmem cache for rate limiter tests to avoid flakiness
Annotation-based traceability (# ISP, # CFG) to allow coverage auditing without reading all the code

Critique of Previous Testing and Measurable Improvements

Anti-Patterns Found in the Old Test Suite

Anti-Pattern 1 Happy-Path-Only Register Serializer Test

Location authentication/tests/test_register_serializers.py (before this sprint)

Problem The registration test only verified that valid data passed the serializer. There were no tests for the following scenarios.

Passwords with a length of exactly 7 (boundary condition that should fail) versus exactly 8 (should pass)
Emails that are already registered but not yet activated (which behave differently from active ones)
The ADMIN role which should not be able to self-register

Why this is weak A mutant changing len(password) < 8 to len(password) <= 8 or len(password) < 7 would survive because no test could distinguish the difference. This is a classic Boundary Value Analysis gap based on Myers' The Art of Software Testing (1979).

Fix Added test_password_exactly_seven_chars_invalid, test_email_already_registered_inactive, and test_role_admin_cannot_register with the annotation # ISP password.length_boundary.

Anti-Pattern 2 StatusChangeService Did Not Test Illegal Transitions

Location pengajuan/tests/test_services.py (before this sprint)

Problem There were only tests for legal transitions (MENUNGGU to DISETUJUI, and MENUNGGU to DITOLAK). There were no tests verifying that backward transitions (DISETUJUI to MENUNGGU) or self-loops (MENUNGGU to MENUNGGU) raise an exception.

Why this is weak A mutant removing one condition in the ALLOWED_TRANSITIONS dictionary would survive. A state machine that is not tested exhaustively could allow status transitions that corrupt data integrity.

Following the principles from Meszaros (xUnit Test Patterns), tests must verify error behavior just as rigorously as happy behavior.

Fix Added 5 CFG tests for illegal transitions with assertions that ensure exceptions are raised.

Anti-Pattern 3 Frontend Tests Did Not Cover API Error Variants

Location tests/features/authentication/components/RegisterForm.test.tsx

Problem The registration form tests only mocked the success scenario (201) and generic errors. There were no tests for the following situations.

HTTP 429 rate limit response which should display a throttling message
HTTP 400 with field-specific errors which should map to the correct fields

Why this is weak A Stryker mutant changing the HTTP status check condition would survive. This is also an Over-Mocked Service smell according to Meszaros, as overly generic mocks do not exercise real branch logic.

Fix Added test_register_form_shows_rate_limit_error with the annotation // ISP ApiError.status.429.

Measurable Improvements (Before and After)

Dimension	Before	After	Delta
Annotated ISP partitions	0 (implicit)	28 (explicit)	+28
Covered CFG illegal transitions	0	5	+5
Mutmut scope (auth and pengajuan)	0 paths	5 new paths	baseline capture enabled
Stryker threshold FE	none	break 70, high 80	active CI guard
Test methods for auth and pengajuan BE	~26	~59	+33
Test methods FE (3 target files)	97	99	+2

Connection to Industry Standards

Google researchers (Petrović et al., ICSE 2021) found that mutation testing is most effective when integrated into the developer workflow as automated feedback rather than just a final report. The Stryker threshold I set implements this pattern by automatically blocking any merge request to staging if the mutation score regresses.

The Stryker Mutator whitepaper (2023) recommends setting coverageAnalysis to "perTest" (which is already active in the config) to isolate mutants to the specific tests that cover them. This reduces false positives and execution time.

Commit Links

BE-GBM MR !158

Commit	Message
`b7564fc5`	`chore(testing) expand mutmut scope to authentication and pengajuan services`
`0c774595`	`[GREEN] test(auth) add ISP partitions for register serializer, activation, and admin verification`
`a2def037`	`[GREEN] test(pengajuan) add CFG prime path coverage for StatusChangeService state machine`

MR Link: [https://gitlab.cs.ui.ac.id/ppl-fasilkom-ui/2026/kelas-d/group1-gb/be-gbm/-/merge_requests/158]

fe-gbm MR !142

Commit	Message
`f18590fe`	`chore(testing) enforce Stryker mutation threshold at 80% high and 70% break`
`42d9b028`	`[GREEN] test(auth) add ISP partitions for RegisterForm and useActivation hook`
`19328728`	`[GREEN] test(pengajuan) add CFG branch coverage for useUpdateStatusPengajuan`

MR Link: `[https://gitlab.cs.ui.ac.id/ppl-fasilkom-ui/2026/kelas-d/group1-gb/fe-gbm/-/merge_requests/142]`

References

Ammann, P. & Offutt, J. (2016). Introduction to Software Testing (2nd ed.). Cambridge University Press. (ISP ch.6, Graph Coverage ch.7).
Jia, Y. & Harman, M. (2011). "An Analysis and Survey of the Development of Mutation Testing." IEEE Transactions on Software Engineering, 37(5), 649-678.
Petrović, G., Ivanković, M., Fraser, G., & Just, R. (2021). "Does Mutation Testing Improve Testing Practices?" ICSE 2021.
Petrović, G. & Ivanković, M. (2018). "State of Mutation Testing at Google." Google Testing Blog.
Meszaros, G. (2007). xUnit Test Patterns Refactoring Test Code. Addison-Wesley.
Stryker Mutator. (2023). "Mutation Testing in Practice." stryker-mutator.io.
Myers, G.J. (1979). The Art of Software Testing. Wiley. (Boundary Value Analysis).

DEV Community: Vincent Davis

Beyond Unit Tests: Implementing BDD and Penetration Testing in GBIM

IR Part A #4 - More Testing: Stress Testing, Penetration Testing, Security Testing, and BDD

Claim Summary

Screenshot Evidence

1. Backend MR Pipeline

2. Frontend MR Pipeline

3. Behave Results

4. integrated testing with CI/CD

Merge Requests and Commit Links

Merge Requests

Backend Commits Used as Evidence

Frontend Commits Used as Evidence

Execution Evidence

Backend Evidence

Backend MR Pipeline 279225 Evidence

Frontend Evidence

Demonstration of Advanced Testing Tools

Security Testing

Penetration Testing

BDD

Stress Testing

Measurable Project Benefits

Literature and Best Practices

Why These References Matter for GBM

Critique of Previous Testing and Quality Improvements

Critique 1: Critical flows were not represented as consolidated executable specifications

Critique 2: Security behavior was not presented as explicit abuse-case coverage

Critique 3: Security scanning was not consistently demonstrated as MR evidence for both FE and BE

Critique 4: Stress testing was not tied to realistic GBM user behavior

Critique 5: Expected protection responses needed to be separated from real failures

Claim Boundaries

Conclusion

Optimizing Test Design Mutation Testing, ISP, and CFG in the GBIM Project

TL;DR

Tools and Methods Used

1. Input Space Partitioning (ISP)

2. Control Flow Graph (CFG) Analysis

3. Mutation Testing

Application to the Project and Evidence of Improvement

ISP Application

CFG Application

mutmut Scope Expansion

Stryker Threshold Enforcement

Benefits, Concrete Data, and Best Practices

Quantitative Data

Connection to Literature

Best Practices Followed

Critique of Previous Testing and Measurable Improvements

Anti-Patterns Found in the Old Test Suite

Anti-Pattern 1 Happy-Path-Only Register Serializer Test

Anti-Pattern 2 StatusChangeService Did Not Test Illegal Transitions

Anti-Pattern 3 Frontend Tests Did Not Cover API Error Variants

Measurable Improvements (Before and After)

Connection to Industry Standards

Commit Links

BE-GBM MR !158

fe-gbm MR !142

MR Link: [https://gitlab.cs.ui.ac.id/ppl-fasilkom-ui/2026/kelas-d/group1-gb/fe-gbm/-/merge_requests/142]

References

MR Link: `[https://gitlab.cs.ui.ac.id/ppl-fasilkom-ui/2026/kelas-d/group1-gb/fe-gbm/-/merge_requests/142]`