PHPackages                             gentry/gentry - PHPackages - PHPackages  [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register)

1. [Directory](/)
2. /
3. [Testing & Quality](/categories/testing)
4. /
5. gentry/gentry

ActiveLibrary[Testing & Quality](/categories/testing)

gentry/gentry
=============

PHP unit test generation tools

0.16.12(1y ago)0983[1 PRs](https://github.com/gentry-php/gentry/pulls)20MITPHPPHP >=8.1

Since Jun 17Pushed 1y ago1 watchersCompare

[ Source](https://github.com/gentry-php/gentry)[ Packagist](https://packagist.org/packages/gentry/gentry)[ RSS](/packages/gentry-gentry/feed)WikiDiscussions master Synced 3w ago

READMEChangelogDependencies (6)Versions (112)Used By (20)

Gentry
======

[](#gentry)

Test generation tools for PHP8+.

Good programmers are lazy, but unfortunately that means that stuff like writing tests (boooooring) is often skipped. Please don't; it's important and oh so handy once you have them in place.

Gentry was designed to make writing tests *so* easy even the worst slacker will bother, and to alleviate writing boilerplate code by generating skeletons for you.

Installation
------------

[](#installation)

```
composer require --dev gentry/gentry
```

You can now run `vendor/bin/gentry`.

Configuration
-------------

[](#configuration)

Create a `Gentry.json` file in the root of your project. It accepts the following options:

```
{
    "src": "/path/to/src",
    "test": "/path/to/testrunner/executable",
    "ignore": "some.*?regex",
    "bootstrap": "/path/to/file",
    "generator": "Fully\\Qualified\\Namespace",
    "output": "/path/to/directory",
    "namespace": "Your\\Preferred\\Namespace"
}
```

### string|array `src`

[](#stringarray-src)

Path(s) to your source files. Can be either absolute or relative to project root - hence`"/path/to/src"` could be simplified to just `"src"`. If you have multiple source paths you may define an array of strings.

Directories are recursed automatically.

### string `test`

[](#string-test)

The command you use to run your (unit)tests for PHP normally (e.g. `vendor/bin/phpunit`).

### string|array `ignore`

[](#stringarray-ignore)

(A) regular expression(s) of classnames to ignore in the `"src"` path. Useful for automatically ignoring classtypes that are hard to test, e.g. controllers. You could also utilise this if your tests and sourcecode are mixed in the same directory (some frameworks like that kind of thing).

### string|array `bootstrap`

[](#stringarray-bootstrap)

The path(s) to file(s) ("bootstrapper(s)") every piece of code in your application needs. This is usually something that would reside in an `index.php`entry point or similar file. These files are otherwise ignored by Gentry when analysing your code and should do stuff like initialise an autoloader.

You can also pass an array of files instead of a string. They will be prepended in order.

> Caution: if `bootstrap`ped files reside inside `src`, they won't be ignored. Gentry uses `require_once` of course, but if these files contain testable features it will try and do something sensible with them.

This isn't necessarily a bad thing; you could actually write tests that test the mock objects you use in other tests :)

### string `generator`

[](#string-generator)

The "generator" used when creating stub tests. For instance, for the `gentry/toast` plugin this would be `Gentry\\Toast`. More about these plugins below. Note that `Gentry\\Toast` in this example is the *namespace*; by default, the actual class should be called `Generator` and extend the abstract base class `Gentry\Gentry\Generator`.

### string `output`

[](#string-output)

The directory where generated tests will be written to. No files will be overwritten; if a guesstimated filename already exists, it will be suffixed with `.1` (or `.2` etc.).

CLI usage
---------

[](#cli-usage)

Now run Gentry from the command line and see what happens:

```
$ vendor/bin/gentry analyze
```

It will complain about zero code coverage, even if you already defined a bunch of tests. Wait, wut? Well, you *do* need to tell Gentry what you've already written tests for.

Modifying existing tests for Gentry compatibility
-------------------------------------------------

[](#modifying-existing-tests-for-gentry-compatibility)

In your tests, instead of simply creating/using stuff, you'll need to build a *wrapped entity*. Entities wrapped by Gentry are "Gentry aware".

To create wrapped entities, we use the `Gentry\Gentry\Wrapper` utility class.

### Wrapping objects

[](#wrapping-objects)

```