Skip to content

Latest commit

 

History

History
127 lines (93 loc) · 4.42 KB

arch-testing.md

File metadata and controls

127 lines (93 loc) · 4.42 KB
title description
Architecture Testing
Architecture testing enables you to specify expectations that test whether your application adheres to a set of architectural rules, helping you maintain a clean and sustainable codebase.

Architecture Testing

Architecture testing enables you to specify expectations that test whether your application adheres to a set of architectural rules, helping you maintain a clean and sustainable codebase. The expectations are determined by either Relative namespaces, fully qualified namespaces, or function names.

toOnlyUse()

The toOnlyUse() method may be used to guarantee that certain classes are restricted to utilizing specific functions or classes. For example, you may ensure your models are streamlined and solely dependent on the Illuminate\Database namespace, and not, for instance, dispatching queued jobs or events.

test('models')
    ->expect('App\Models')
    ->toOnlyUse('Illuminate\Database');

toOnlyBeUsedIn()

The toOnlyBeUsedIn() method enables you to limit the usage of a specific class or set of classes to only particular parts of your application. For instance, you can use this method to confirm that your models are only used by your repositories and not by controllers or service providers.

test('models')
    ->expect('App\Models')
    ->toOnlyBeUsedIn('App\Repositories');

toBeUsed()

The not modifier, when combined with the toBeUsed() method, enables you to verify that certain classes or functions are not being utilized by your application.

test('globals')
    ->expect(['dd', 'dump'])
    ->not->toBeUsed();

test('facades')
    ->expect('Illuminate\Support\Facades')
    ->not->toBeUsed();

toBeUsedIn()

By combining the not modifier with the toBeUsedIn() method, you can restrict specific classes and functions from being used within a given namespace.

test('globals')
    ->expect('request')
    ->not->toBeUsedIn('App\Domain');

test('globals')
    ->expect('Illuminate\Http')
    ->not->toBeUsedIn('App\Domain');

toUse()

By combining the not modifier with the toUse() method, you can indicate that files within a given namespace should not use specific functions or classes.

test('globals')
    ->expect('App\Domain')
    ->not->toUse('request');

test('globals')
    ->expect('App\Domain')
    ->not->toUse('Illuminate\Http');

toUseNothing()

If you want to indicate that particular namespaces or classes should not have any dependencies, you can utilize the toUseNothing() method.

test('value objects')
    ->expect('App\ValueObjects')
    ->toUseNothing();

ignoring()

When defining your architecture rules, you can use the ignoring() method to exclude certain namespaces or classes that would otherwise be included in the rule definition.

test('facades')
    ->expect('Illuminate\Support\Facades')
    ->not->toBeUsed()
    ->ignoring('App\Providers');

In some cases, certain components may not be regarded as "dependencies" as they are part of the native PHP library. To customize the definition of "native" code and exclude it during testing, Pest allows you to specify what to ignore.

For example, if you do not want to consider Laravel a "dependency", you can use the arch() method inside the beforeEach() function to disregard any code within the "Illuminate" namespace. This approach allows you to focus only on the actual dependencies of your application.

// tests/Pest.php
uses()->beforeEach(function () {
    $this->arch()->ignore([
        'Illuminate',
    ])->ignoreGlobalFunctions();
})->in('Feature');

In this section, you have learned how to perform architectural testing, ensuring that your application or library's architecture meets a specified set of architectural requirements. Moving on, let's explore how to test the coverage of your testing code: Test Coverage