- What is pragmarx/tddd and what does it do?
- TDDD (Test Driven Development Dashboard) is a Laravel package that gives you a live web dashboard for your test suite. It wraps PHPUnit execution with a file watcher and streams pass/fail results, timings and failure details to a self-hosted browser page as you code. It is a developer-experience tool, not a runtime dependency, so it belongs in require-dev and never touches your application code, models or production boot path.
- How do I install TDDD in a Laravel application?
- Install it as a dev dependency with composer require --dev pragmarx/tddd. On modern Laravel the service provider is auto-discovered, then you publish the config file and start the dashboard. Total integration effort is measured in hours: a dev-only require, a published config, and a dashboard route/port. Nothing in your application code changes, and rollback is a single composer remove --dev.
- Which Laravel, PHP and PHPUnit versions does TDDD support?
- Compatibility is gated by three things: your PHP minor version, the Laravel major, and the PHPUnit major. Because the package parses PHPUnit output, PHPUnit major bumps are the most likely breakage point, followed by Laravel majors. Before standardizing, verify the current supported matrix in the package README or CI config, and pin versions in your require-dev block during the trial.
- Does TDDD's file watcher work inside Docker, WSL2, or on macOS?
- This is the biggest practical unknown and should be validated in a short spike before team-wide adoption. Watchers typically rely on inotify-style filesystem events, which are historically unreliable across Docker volume mounts, WSL2 and macOS. Test the specific mechanism your version uses on the exact environment your team develops in, and confirm it picks up saves reliably rather than silently missing changes.
- Is it safe to run the TDDD dashboard in production?
- No. TDDD is a require-dev developer tool and should never be deployed or left running on a production host. Verify that the dashboard binds to 127.0.0.1 by default and, if you change the binding for any reason, that appropriate auth and CSRF protections are in place. Treat it like any other local dev server: loopback only, never exposed.
- Does TDDD work with Pest or ParaTest and parallel test runners?
- TDDD is built around a single PHPUnit process, so Pest and ParaTest compatibility is unproven and should be validated with a spike before you standardize on it. Parallel runners produce interleaved or per-worker output that a parser written for a single PHPUnit stream may not handle correctly. If your team is PHPUnit-only and Laravel-native, fit is close to drop-in; otherwise test first.
- Is there a headless or CI mode in TDDD, or is it strictly for local development?
- TDDD is an interactive developer tool aimed at keeping the red-green-refactor loop visible while you work locally. Check the README for any documented headless or CI-adjacent mode before assuming one exists. For CI reporting, keep using your existing PHPUnit output, JUnit XML or coverage artifacts and treat TDDD as a local convenience layer.
- How do I change the dashboard port or route used by TDDD?
- After installing, publish the package config and adjust the route and port values there rather than editing vendor files. Keep the binding on localhost unless you have a specific, secured reason to do otherwise. If a port collision occurs with Vite, Sail or another local service, change the TDDD port in config and restart the dashboard process.
- Is pragmarx/tddd actively maintained, and how risky is adopting it?
- It is a 712-star, MIT-licensed, single-maintainer dev tool with essentially zero downstream dependents, so ecosystem validation is thin. Check commit cadence and issue-response history over the last 12 months before committing. The upside is that the risk is skewed toward developer annoyance rather than production incidents, since nothing ships beyond require-dev and removal is a one-line Composer command.
- What are the alternatives to TDDD, and should I still try it?
- Alternatives include terminal watch loops, PHPUnit's own output, editor-integrated test runners, and Pest's built-in watch mode if you use Pest. TDDD's strongest argument is asymmetry: trivial to adopt, trivial to abandon, with no application changes. Run it on one developer's machine for one to two weeks, compare against your terminal baseline, then decide on team-wide standardization.