> ## Documentation Index
> Fetch the complete documentation index at: https://kawax.biz/llms.txt
> Use this file to discover all available pages before exploring further.

# Packageontwikkeling met Testbench Workbench

> Hoe je met Orchestra Testbench Workbench een verificatieomgeving bouwt die dicht bij een echte app ligt, compleet met routes, migrations en het starten van de service.

## Wat is Testbench Workbench?

[Orchestra Testbench](https://github.com/orchestral/testbench) is bedoeld voor tests, maar in combinatie met Workbench kun je binnen je package-repository een kleine Laravel-app bouwen en lokaal draaien.

Je gebruikt het als aanvulling op de tests uit `package-testing`, wanneer je UI-controles, routebereikbaarheid en verificatie met seeders wilt uitvoeren.

```mermaid theme={null}
flowchart TD
    A["Package zelf<br>`src/`"] --> B["Workbench<br>`workbench/`"]
    B --> C["WorkbenchServiceProvider<br>registratie voor demo"]
    B --> D["Routes en controllers<br>schermcontrole"]
    B --> E["Migrations en seeders<br>dataverificatie"]
    B --> F["`composer serve`<br>lokaal starten"]
    C --> G["testbench.yaml<br>provider-/buildconfiguratie"]
```

## Setup

<Steps>
  <Step title="Installeer Testbench">
    ```bash theme={null}
    composer require --dev orchestra/testbench
    ```
  </Step>

  <Step title="Maak de Workbench aan">
    ```bash theme={null}
    vendor/bin/testbench workbench:install
    ```

    Dit commando doet het volgende in één keer:

    * De directorystructuur van `workbench/` aanmaken
    * De Workbench-namespace toevoegen aan `autoload-dev` in `composer.json`
    * Buildcommando's toevoegen aan de `scripts` van `composer.json`

    <Tip>
      Extra opties:

      * `--force` : bestaande bestanden overschrijven
      * `--basic` : een eenvoudige opzet zonder routes en package-discovery-configuratie
      * `--devtool` : DevTool-ondersteuning inschakelen
    </Tip>
  </Step>

  <Step title="Bouwen en starten">
    ```bash theme={null}
    composer clear
    composer prepare
    composer build
    vendor/bin/testbench serve
    ```
  </Step>
</Steps>

<Info>
  `workbench:install` richt de map `workbench/`, `autoload-dev` en de bijbehorende scripts in één keer in.
</Info>

Na de installatie zijn de volgende scripts toegevoegd aan `composer.json`.

```json theme={null}
{
    "autoload-dev": {
        "psr-4": {
            "Tests\\": "tests/",
            "Workbench\\App\\": "workbench/app/",
            "Workbench\\Database\\Factories\\": "workbench/database/factories/",
            "Workbench\\Database\\Seeders\\": "workbench/database/seeders/"
        }
    },
    "scripts": {
        "post-autoload-dump": [
            "@clear",
            "@prepare"
        ],
        "clear": "@php vendor/bin/testbench package:purge-skeleton --ansi",
        "prepare": "@php vendor/bin/testbench package:discover --ansi",
        "build": "@php vendor/bin/testbench workbench:build --ansi",
        "serve": [
            "Composer\\Config::disableProcessTimeout",
            "@build",
            "@php vendor/bin/testbench serve --ansi"
        ]
    }
}
```

## De ontwikkelomgeving definiëren met testbench.yaml

Het gedrag van Workbench beheer je met een `testbench.yaml` in de root.

<Warning>
  Omdat `testbench.yaml` per omgeving verschillende instellingen kan bevatten, wordt aanbevolen het toe te voegen aan `.gitignore` en buiten de commits te houden. Neem in plaats daarvan een `testbench.yaml.example` als template op in de repository.
</Warning>

```yaml theme={null}
providers:
  - Vendor\Package\PackageServiceProvider
  - Workbench\App\Providers\WorkbenchServiceProvider

migrations:
  - workbench/database/migrations

workbench:
  start: '/'
  install: true
  health: false
  discovers:
    web: true
    api: false
    commands: false
    components: false
    views: false
    config: true
  build:
    - asset-publish
    - create-sqlite-db
    - db-wipe
    - migrate-fresh:
        --seed: true
        --seeder: Workbench\Database\Seeders\DatabaseSeeder
  assets:
    - laravel-assets
```

De belangrijkste configuratieopties:

| Sleutel               | Toelichting                                                             |
| --------------------- | ----------------------------------------------------------------------- |
| `providers`           | Lijst van service providers die in de Workbench-omgeving worden geladen |
| `migrations`          | De migrationmappen die worden uitgevoerd                                |
| `workbench.start`     | De standaard-URL bij het starten van `composer serve`                   |
| `workbench.discovers` | Bepaalt wat de automatische package discovery van Laravel meeneemt      |
| `workbench.build`     | Lijst van commando's die tijdens de build worden uitgevoerd             |

Ook environment variables kun je in `testbench.yaml` beheren.

```yaml theme={null}
env:
  - APP_ENV=testing
  - APP_KEY=base64:your-app-key
  - DB_CONNECTION=sqlite
  - DB_DATABASE=:memory:
```

## De directorystructuur van workbench

<Tree>
  <Tree.Folder name="workbench" defaultOpen>
    <Tree.Folder name="app" defaultOpen>
      <Tree.Folder name="Http">
        <Tree.Folder name="Controllers" />
      </Tree.Folder>

      <Tree.Folder name="Models" />

      <Tree.Folder name="Providers">
        <Tree.File name="WorkbenchServiceProvider.php" />
      </Tree.Folder>
    </Tree.Folder>

    <Tree.Folder name="bootstrap" />

    <Tree.Folder name="config" />

    <Tree.Folder name="database" defaultOpen>
      <Tree.Folder name="factories" />

      <Tree.Folder name="migrations" />

      <Tree.Folder name="seeders">
        <Tree.File name="DatabaseSeeder.php" />
      </Tree.Folder>
    </Tree.Folder>

    <Tree.Folder name="public" />

    <Tree.Folder name="resources">
      <Tree.Folder name="views" />
    </Tree.Folder>

    <Tree.Folder name="routes">
      <Tree.File name="web.php" />

      <Tree.File name="api.php" />

      <Tree.File name="console.php" />
    </Tree.Folder>

    <Tree.Folder name="storage" />
  </Tree.Folder>
</Tree>

## De belangrijkste functies van Workbench

### WorkbenchServiceProvider

Maak een Workbench-specifieke service provider voor de demoregistraties.

```php theme={null}
<?php

namespace Workbench\App\Providers;

use Illuminate\Support\ServiceProvider;
use Vendor\Package\SomeClass;
use Workbench\App\Services\DemoService;

class WorkbenchServiceProvider extends ServiceProvider
{
    public function register(): void
    {
        $this->app->singleton(DemoService::class);
    }

    public function boot(): void
    {
        SomeClass::register('demo', DemoService::class);
        $this->loadRoutesFrom(__DIR__.'/../../routes/web.php');
        $this->loadViewsFrom(__DIR__.'/../../resources/views', 'workbench');
    }
}
```

### Routes en controllers

In `workbench/routes/web.php` en `workbench/routes/api.php` kun je verificatieroutes plaatsen.

```php theme={null}
use Illuminate\Support\Facades\Route;
use Vendor\Package\Facades\Package;

Route::get('/', function () {
    return Package::status();
});
```

### Migrations en seeders

Met `workbench/database/migrations` en `workbench/database/seeders` verifieer je met een datastructuur die dicht bij productie ligt.

```php theme={null}
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;

Schema::create('widgets', function (Blueprint $table) {
    $table->id();
    $table->string('name');
    $table->timestamps();
});
```

Met een seeder genereer je testdata.

```php theme={null}
<?php

namespace Workbench\Database\Seeders;

use Illuminate\Database\Seeder;
use Workbench\Database\Factories\UserFactory;

class DatabaseSeeder extends Seeder
{
    public function run(): void
    {
        UserFactory::new()->count(10)->create();
    }
}
```

### De service starten en CLI-controles

Via `vendor/bin/testbench` kun je Artisan-commando's uitvoeren.

```bash theme={null}
vendor/bin/testbench list
vendor/bin/testbench route:list
vendor/bin/testbench migrate:fresh --seed
```

## Testen met de WithWorkbench-trait

Met de `WithWorkbench`-trait wordt de configuratie uit `testbench.yaml` ook op je geautomatiseerde tests toegepast.

```php theme={null}
<?php

namespace Tests;

use Orchestra\Testbench\Concerns\WithWorkbench;
use Orchestra\Testbench\TestCase as Orchestra;

abstract class TestCase extends Orchestra
{
    use WithWorkbench;

    protected function getPackageProviders($app): array
    {
        return [
            \Vendor\Package\Providers\YourServiceProvider::class,
        ];
    }

    protected function defineEnvironment($app): void
    {
        $app['config']->set('database.default', 'testing');
        $app['config']->set('your-package.key', 'test-value');
    }
}
```

## Samenwerking met je tests

Het werkt het prettigst als je de rollen verdeelt: Workbench als "app voor handmatige controle en demo's" en de Testbench-testcode als "geautomatiseerde verificatie".

* Automatisering: regressies voorkomen in `tests/`
* Handmatige controle: schermen, flows en integratiegedrag controleren in `workbench/`

## Probleemoplossing

```bash theme={null}
# Wissen en volledig herbouwen
composer clear && composer prepare && composer build

# De automatische package discovery controleren
vendor/bin/testbench package:discover --ansi

# De configuratie controleren
vendor/bin/testbench about

# De routelijst controleren
vendor/bin/testbench route:list
```

<AccordionGroup>
  <Accordion title="De Workbench bouwt niet">
    Controleer de syntaxis van `testbench.yaml` en de providerconfiguratie. Een YAML-indentatiefout is een veelvoorkomende oorzaak.
  </Accordion>

  <Accordion title="Routes worden niet geladen">
    Controleer het pad van het routebestand en de registratie in de WorkbenchServiceProvider. Kijk of `discovers.web` in `testbench.yaml` op `true` staat.
  </Accordion>

  <Accordion title="Er treedt een databasefout op">
    Controleer of het pad naar de migrations klopt. Gebruik je SQLite, kijk dan of de buildstap `create-sqlite-db` is opgenomen.
  </Accordion>
</AccordionGroup>

## Gerelateerde pagina's

<Columns cols={2}>
  <Card title="Laravel-packages testen met Orchestra Testbench" icon="flask-conical" href="/nl/advanced/package-testing">
    Bekijk eerst hoe je een testinfrastructuur voor packages opzet.
  </Card>

  <Card title="Versiecompatibiliteit van packages beheren" icon="git-branch" href="/nl/advanced/package-versioning">
    Bekijk de compatibiliteitstabel van Laravel en Testbench en het beheer van de CI-matrix.
  </Card>
</Columns>

<Info>
  Source: [invokable/laravel-bluesky docs/workbench.md](https://github.com/invokable/laravel-bluesky/blob/main/docs/workbench.md), [Orchestra Testbench](https://github.com/orchestral/testbench)
</Info>


## Related topics

- [Laravel-packages testen met Orchestra Testbench](/nl/advanced/package-testing.md)
- [Laravel Package Skeleton — officiële startertemplate voor packages](/nl/blog/package-skeleton-introduction.md)
- [De interne structuur van package discovery](/nl/advanced/package-discovery.md)
- [Statische analyse van packages (PHPStan / Larastan)](/nl/advanced/package-static-analysis.md)
- [Laravel-packages ontwikkelen](/nl/advanced/package-development.md)