pestphp / pest Goto Github PK

Using the following code:

public function trigger_test_warning() {
    $this->expectWarning();
    $this->expectWarningMessage('test warning');

    trigger_error('test warning', E_USER_WARNING);
}

The test fails with the following error message:

Failed asserting that exception of type "Whoops\Exception\ErrorException" matches expected exception "PHPUnit\Framework\Error\Error". Message was: "test warning" at
  /vendor/pestphp/pest/src/Factories/TestCaseFactory.php:132
  /vendor/pestphp/pest/src/Concerns/TestCase.php:141
  /vendor/pestphp/pest/src/Support/ExceptionTrace.php:24
  /vendor/pestphp/pest/src/Concerns/TestCase.php:142
  /vendor/pestphp/pest/src/Concerns/TestCase.php:135
  /vendor/pestphp/pest/src/Console/Command.php:120

The test runs perfectly in PHPUnit, and only errors out when running Pest. Does Pest support PHP trigger_error?

Across all the repositories we are using this as require-dev:

        "ergebnis/phpstan-rules": "^0.14.4",
        "friendsofphp/php-cs-fixer": "^2.16.3",
        "phpstan/phpstan": "^0.12.25",
        "phpstan/phpstan-strict-rules": "^0.12.2",
        "rector/rector": "^0.7.25",
        "symfony/var-dumper": "^5.0.8",
        "thecodingmachine/phpstan-strict-rules": "^0.12.0"

Would be cool to create an repository https://github.com/pestphp/pest-dev-tools that contains all of that.

Fell free to perform a pull request.

Gonna keep this updated with things I find today as I rewrite my tests to Pest

• The test contents are inverted in this page of the docs. On the let's head over to both ..Test.php files and modify the content to: the unit has feature test contents and otherwise.
• It's somewhat annoying I can't use routes in higher-order tests [1]
• Being able to incrementally-adopt Pest is really really nice
• I think Reinink already said it, but a Pest shift would be really useful for migration
• IDE autocompletion is way better than I thought it'd be, but it's annoying that the return values of the $this-> methods are not detected, and especially annoying when working with TestResponses (using VSCode)
• Really missed using the Better PHPUnit extension by Caleb, which allows you to run a test while you're inside the code by pressing cmd+t, so I made a fork that works with Pest.
• When porting tests I expected assertGuest() to work the same as assertCount() but it seems the magic methods are limited to PHPUnit's default assertions. I understand this is supposed to be Laravel agnostic, but it would be cool to have all TestClass methods available without $this.
• I don't know if this is possible, but setting groups per file (and then merging in custom defined ones on individual tests) would be useful to avoid repetition.
• I assume this is in the roadmap, but it would be nice if Collision's php artisan test command ran Pest if it's installed, or at least provided some way of customizing the binary-

[1]:

Hi! Right now, it looks like the Pest.php & Helpers.php have to be in the "/tests" directory for them to load. What if my projects tests are not in "/tests", but in another directory, configured through the phpunit.xml file?

Ideally, I would like to have the Pest.php, Helpers.php, Datasets, etc in the root of my own tests directory. Because they feel (especially the helpers & datasets) as part of my test files.

Is there a clean way to do this?

Problem:
Every time you want to check your code coverage, you have to repeat the --min=70 command line option.

Suggestion:
This target value should be set once per project in a config file:

• It would save a few keystrokes / lighten the cognitive load of remembering the syntax
• Every collaborator would be on the same page
• It wouldn't prevent revising the target later on

It could be set in a configuration file in the project, and then read every time we run pest --coverage.
Candidate for hosting this value:

• phpunit.xml
• pest.php

Pest will mark the following test as risky. PHPUnit will mark it as passed.

use Illuminate\Log\Logger;
use Mockery as m;
use Monolog\Logger as Monolog;

test('example', function (): void {
    $writer = new Logger($monolog = m::mock(Monolog::class));
    $monolog->shouldReceive('error')->once()->with('foo', []);

    $writer->error('foo');
});

At long term, I wanna pest to run on its own. Would be cool an page on the website ( like https://vuejs.org/v2/guide/team.html or better ) where people understand the different concerns of the project and the people involved on those concerns.

Something interesting came up during our Laracon break talk, regarding the Pest logo.

Concerns:
We wonder if people suffering from epilepsy would be affected by the animated logo on Pest's home page.

Resources:

• An actual academic testing tool: Photosensitive Epilepsy Analysis Tool (PEAT)
• A Guide to use this tool
• MDN's accessibility recommendations

Workaround:
I tried a slowed down version of the current logo:
https://ezgif.com/speed/ezgif-1-325dcc77bf08.gif

I find 10% seems whimsical enough, still convey the intended vibe and shouldn't be as dangerous?

I will take some time to dig through that, and would love to hear from people competent on the matter about this topic!

Currently builds are failing on windows: https://github.com/pestphp/pest/runs/704328906?check_suite_focus=true.

Some help would be appreciated here.

Curious, what are your thoughts about implementing the standard describe blocks?

Ala?

https://jestjs.io/docs/en/api#describename-fn

Example

describe('my block', function() {
  test('is delicious', function() {
    assertTrue(true);
  });
});

When chaining multiple higher order methods it can happen, that one assertion does not return the target instance and simply returns null or nothing.

For example

it('exposes the plugin class via composer.json')
    ->assertArrayHasKey('extra', $data)
    ->assertArrayHasKey('pest', $data['extra']);

does not work because assertArrayHasKey returns null. So the second assertion breaks.

The idea would be to keep the initial target and reuse it when a chain method does not return a value.

    public function chain(object $target): void
    {
        $originalTarget = $target;

        foreach ($this->messages as $message) {
            $target = $message->call($target);

            if ($target === null) {
                $target = $originalTarget;
            }
        }
    }

What do you think?

Hi 👋, I have been using pest and reading his documentation. It's useful to have an option to skip a specific test with ->skip() and also to run a single test with ->only().

Nice work!

I have a question, is it required to set the minimum-stability in our composer.json?

Because if not exist the option for "minimum-stability" I can't require pest and I get this error:

$ composer require pestphp/pest --dev

Using version ^0.1.5 for pestphp/pest
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Installation request for pestphp/pest ^0.1.5 -> satisfiable by pestphp/pest[v0.1.5].
    - pestphp/pest v0.1.5 requires nunomaduro/collision ^5.0 -> satisfiable by nunomaduro/collision[v5.0.0-BETA1] but these conflict with your requirements or minimum-stability.


Installation failed, reverting ./composer.json to its original content.

Now, if I add the minimum-stability in composer.json like this:

{
    "name": "a/b",
    "minimum-stability": "dev",
    "require": {},
    "require-dev": {
        "phpunit/phpunit": "^9.0"
    }
}

Then pest it's installed ok and I can use ./vendor/bin/pest

Hi all ! Just found this when I launches vendor/bin/pest tests --coverage for the first time :(

• Issue: Coverage not found in path: /Users/liorchamla/code/angsym8/_php/07-csv-tests/vendor/pestphp/pest/.temp/coverage.php.
• PHP version: 7.4.3
• Operating system: Darwin

To notice : I have pecl.php.net/xdebug-2.9.2

Hello!

I successfully run unit test with pest, but while i'm trying to make browser tests - there is no output of pest.
Laravel

tests/TestCase.php

`<?php

namespace Tests;

use Illuminate\Foundation\Testing\TestCase as BaseTestCase;

abstract class TestCase extends BaseTestCase
{
use CreatesApplication;

}`

tests/Feature/VinTest.php

`<?php

it('strona glowna')->get('/')->assertSee('szybka wysyłka');`

Results of tests is misssing with errors or any output.

~/dev$ ./pest tests/Feature/VinTest.php
~/dev$

Would you like to hint me, how to debug it ?

With regards,
Pawel Sosnicki

Just trying to do something like

<?php

it("should retrieve model data", function () {
    $data = \App\User::all();
    assertTrue($data);
});

Throws the following

1) /Users/mikee/Documents/code/xxx/tests/Unit/PestTest.php::it test model
  Error: Call to a member function connection() on null

Sometimes you expect an exception to be thrown but just want to perform an assertion. For example in the Laravel tests we may use $this->withoutExceptionHandling(); It would be nice to be able to performe assertions eventhough some exception is being thrown.

Maybe the use could be:

it('performs an assertion eventhough everything is going wrong', function(){
    User::create(); // create a user without a username and lets assume its required and not nullable
    $this->assertDatabaseMissing('users', [
        'name' => null
    ]);
})->withoutExceptionHandling();

I'm trying to understand how Helpers work. I'm doing a set of helpers for Api call assertions and the first test is passing but the second one is saying that the method doesn't exists in TestCase. How could we use those helpers using High Order tests?

// It works
test('all fields can be null updating user info', fn () => assertApiCallOk('PUT', '/api/user'));

// It throws Call to undefined method Tests\TestCase::assertApiCallOk()
test('all fields can be null updating user info 2')->assertApiCallOk('PUT', '/api/user');

And this is the declaration inside Helpers.php

/**
 * Asserts that the api call returns an ok response.
 */
function assertApiCallOk(string $verb, string $url = '', array $payload = []): TestResponse
{
    return test()->json($verb, $url, $payload)->assertOk();
}

Thanks!

A simple page for this should suffice. I'm thinking

• Document that pest forwards all arguments to PHPUnit. For example, I often use --filter to cut down on test time when I'm working on a specific feature.
• Document pest specific arguments (--coverage and --min). This would be in addition to the coverage page.

I wish there could be a scoped-phar version of Pest, to allow downloading in a blink of an eye without having to check anything on the current project, and without pest having compatibility issues with PHPUnit, nor the need for PHPUnit by the way.

PHPUnit has a scoped phar since version 8.1, and it has a special list of scripts to generate this scoped phar: https://github.com/sebastianbergmann/phpunit/tree/master/build/scripts

There's more documentation on how to achieve this there:

• sebastianbergmann/phpunit#2015
• sebastianbergmann/phpunit#3086
• sebastianbergmann/phpunit#3575

I hope this helps :)

I really wanted to contribute on this specific point, but I'm sadly completely overwhelmed by work and really tough personal issues, and I don't want to work on something I might not have time to do 😞

In line with other testing frameworks, a test that has no function should not throw warnings when there are no assertions. Example of this (using a fake service)

<?php

use App\Services\CalculatorService;


// This should be a valid state
it('can subtract');

// This is fine to throw a warning or an error
it('can add', function() {
        $calculator = new CalculatorService();
	$calculator->add(1,2);
});

Currently both of these throws warnings. I suggest the first should just show yellow highlighted text with no warning and the second should throw a warning.

Just an idea. Would be cool to replicate ( automatically ) our changelog. Just like we in phpinsights: https://phpinsights.com/changelog.html#v1-14-0.

Once we don't have Discussions tab:

I use pcov to run coverage reports. So i just enable it when need, to avoid performance issues when TDDing.

 "scripts": {
        "pest": "./vendor/bin/pest",
        "coverage": "php -dpcov.enabled=1 ./vendor/bin/pest --coverage --colors=always",
}

RUN composer coverage

Colors works as expected on test output

But coverage section have no colors.

Is there any workarounds?

I need to set some parameters parameters in test class before Laravel application creates. How can I do that?

Not sure I missed that or not, but when I run

vendor/bin/pest --version

I get

PHPUnit 9.1.5 by Sebastian Bergmann and contributors.

but I expect to get

Pest 0.1.5

or something similar. In my case, this information is needed to display what framework and what particular its version is used when running Infection PHP for with Pest.

Related to #4

I added a new line in my Pest.php, below uses(TestCase::class)->in('Feature');:
uses(RefreshDatabase::class)->in('Feature');

Like suggested in https://pestphp.com/docs/underlying-test-case/

After some debugging, with no functionality from TestCase::class, I figured out I had to combine these, or else the latter will override the former, leaving TestCase functionality out of my tests.

This gave me errors like

InvalidArgumentException
Unable to locate factory for [App\Category].

and

Error
Call to undefined method Tests\Feature\AddingStatementsToCategoriesTest::get()

when trying to use pestphp on Laravel 7.

I fixed it all this way:

uses(TestCase::class, RefreshDatabase::class)->in('Feature');

Maybe the documentation could be clearer about this, or I'm just stupid for trying ;-).

In the current state of Pest, we could say that PHPUnit static functions like assertions are being injected in the global namespace, and functions specific to the test case are being served thought the $this variable. Here is an example:

<?php

beforeEach(fn () => $this->withoutMiddleware()); // `$this` being used

test('example test', function () {
    assertTrue(true); // `assertTrue` function being used
});

it('has welcome page', function () {
    $this->get('/')->assertSee('Laravel'); // `$this` being used
});

The current approach has a few problems: there is no autocompletion on the $this, and for some developers gets complicated to understand what is available globally and what's available on the $this.

Proposal: Serve namespaced functions for assertions/methods specific to the test case.

✓ No more autocompletion issues
✓ Makes things a little bit more consistent as everything gets available using just simple functions

PHPUnit static functions like assertTrue or assertArrayHas will be still available globally, but assertions/methods specific to the test case would require a use statement. Here is how it could look like:

<?php

use function Pest\Laravel\{get, withoutMiddleware};

beforeEach(fn () => withoutMiddleware());

test('example test', function () {
    assertTrue(true);
});

it('has welcome page', function () {
    get('/')->assertSee('Laravel');
});

The $this is still available for people that want to copy/paste the current PHPUnit test. So no breaking changes are being proposed here.

I am still not sure about this, as it requires one or more extra lines per test. So let me know.

When I run

vendor/bin/pest --colors=never

Pest continues printing ascii chars that produces the following text:

  �[37;41;1m FAIL �[39;49;22m�[39m PestExample\Test\PhpUnitSourceFileTest�[39m
  �[31;1m•�[39;22m�[39m �[2mit can add two integers�[22m�[39m

  �[2m---�[22m

  �[31;1m• PestExample\Test\PhpUnitSourceFileTest �[39;22m> �[31;1mit can add two integers�[39;22m
  �[41;1m Error �[49;22m

�[39;1m  Call to protected method PestExample\SourceFile::add() from context 'PestExample\Test\PhpUnitSourceFileTest'�[39;22m

  at �[32mtests/PhpUnitSourceFileTest.php�[39m:�[32m18�[39m
     14▕     public function test_it_can_add_two_integers(): void
     15▕     {
     16▕         $source = new SourceFile();
     17▕ 
  ➜  18▕         $result = $source->add(3, 2);
     19▕ 
     20▕         $this->assertGreaterThan(0, $result);
     21▕     }
     22▕ }



  �[37;1mTests:  �[39;22m�[31;1m1 failed�[39;22m
  �[37;1mTime:   �[39;22m�[39m0.03s�[39m

For example, when I use --colors=never with PHPUnit, it correctly disables and prints just raw text:

PHPUnit 9.1.5 by Sebastian Bergmann and contributors.

.                                                                   1 / 1 (100%)

Time: 00:00.046, Memory: 6.00 MB

Related to #4 (In Infection PHP, we need a "raw" output without all those colours for terminal to parse the text);

Even without Infection, it's still the issue as some CI do not support such output as well

TL; DR: This RFC it's about the $this binding of the given closures to the underlying PHPUnit test case class - It proposes the uses function that you can use to instruct Pest to use a specific class/trait at a file-level or directory-level.

Summary

By default, every given closure to globals functions of Pest is always bound to the current test case. As an example, on the code below, the $this is bound to PhpUnit\Framework\TestCase.

it('has welcome page', function () {
    echo get_class($this); // Uses PhpUnit\Framework\TestCase
});

The goal of binding the closure to $this is giving access to underlying functionalities that may exist in current test case classes of the PHP Ecosystem - just like the Laravel's test case class.

To swap the underlying test case class, Pest proposes the usesfunction that can instruct Pest to use a specific class/trait a file level or at directory level. Here is an example with the Laravel Framework:

• Per directory directive:

// Tests/Pest.php:
uses(TestCase::class, RefreshDatabase::class)->in('Features');

// Tests/Features/Example.php:
it('has welcome page', function () {
    echo get_class($this); // Uses Tests\TestCase + RefreshDatabase trait
});

• Per file directives:

Of course, you can also improve the granularity of this, using the uses function at file level:

// Tests/Pest.php:
uses(TestCase::class)->in('Features');

// Tests/Features/Example.php:
uses(RefreshDatabase::class);

it('has welcome page', function () {
    echo get_class($this); // Uses Tests\TestCase + RefreshDatabase trait
});

One of the main goals of Pest is to provide seamless integration with Laravel. Everything should fell really natural and sexy. Let me know what do you think?

I'm working on converting my tests over to Pest. (Its awesome, Thanks!), When I run vendor/bin/pest I get 50 passed tests, roughly half are in FolderA, and the other half are in FolderB

in my Pest.php I have something like

uses(ProjectATestCase::class)->group('a')->in('FolderA');
uses(ProjectBTestCase::class)->group('b')->in('FolderB');

but now when I run a group only my actual pest tests run, which means I'm missing quite a few

vendor/bin/pest --group=a # 3 passed tests
vendor/bin/pest --group=b # 18 passed tests

Not sure if this is a bug, or intended, but it definitely surprised me (although soon it will all be switched over so not a problem)

Hi,

I've come across the following bug.

When using a capitalized acronym inside the test's description (e.g. API), when running the test it will be printed lowercase and a space will be added between each characters.

Code sample

it('requires an API key', function () {
    assertTrue(true);
});

This gets printed as:

PASS  Tests\Unit\TranslatorTest
✓ it requires an  a p i key

Tests:  1 passed
Time:   0.03s

Expected result
The description should probably be printed as is. If this is not possible, capitalized acronyms at least should be preserved.

Steps to reproduce

1. Create a new dummy test
2. Use a capitalized acronym inside the description (e.g. API)
3. Run the test
4. See that the printed description now shows the acronym as a p i instead of API

Have a nice day.

Hey all, as Nuno asked me to, I post this new issue referencing #12 : when you ask for --coverage you must have a whitelist in order to tell PHPUnit which files you want to monitor for coverage.

For now, you will just have a ShouldNotHappenException which states that coverage could not be done.

It could be usefull for beginners (like me) to suggest that maybe a whitelist is missing or even to prevent the use of --coverage option if no whitelist is set in the command nor in the phpunit.xml ?

I will try to see if I can do this by myself and give you all a PR but I'm not sure I'm competent enough and wont have time to do it soon, so if someone wants to give it a try, let's go 👍

Just committed something kind of experimental to the dev-master.

Feature added: The test helper called without any arguments resolves the current test instance.

Use Case 1: Creation of helpers that depend of the current test instance. I think this is dope.

<?php

function actingAs($user)
{
    return test()->actingAs($user);
}

it('has home', function () {
    $user = factory(User::class)->create();

    actingAs($user)->get('/')->assertStatus(200);
});

Use Case 2: Solves some IDE issues ( see #5):

<?php

it('does something', function () {
    test()->assertAuthenticat.. // <- IDE support here.
});

Any thoughts on this? You can try it out doing:

composer require pestphp/pest:dev-master

How to reproduce:

Source class:

# src/SourceFile.php

namespace PestExample;

final class SourceFile
{
    public function add(int $a, int $b): int
    {
        return $a + $b;
    }
}

test file:

# tests/SourceFileTest.php

use PestExample\SourceFile;

it('can add two integers', function (): void {
    $source = new SourceFile();

    $result = $source->add(3, 2);

    $this->assertGreaterThan(0, $result);
});

Command line:

vendor/bin/pest --coverage-xml=pest-coverage-xml --log-junit="pest-coverage-xml/junit.xml"

generated files:

tree pest-coverage-xml

pest-coverage-xml
├── SourceFile.php.xml
├── index.xml
└── junit.xml

And the incorrect junit.xml report looks like:

<?xml version="1.0" encoding="UTF-8"?>
<testsuites>
  <testsuite name="" tests="1" assertions="1" errors="0" warnings="0" failures="0" skipped="0" time="0.006614">
    <testsuite name="P\Tests\SourceFileTest" file="/pest-example/vendor/pestphp/pest/src/Factories/TestCaseFactory.php(185) : eval()'d code" tests="1" assertions="1" errors="0" warnings="0" failures="0" skipped="0" time="0.006614">
      <testcase name="it can add two integers" assertions="1" time="0.006614"/>
    </testsuite>
  </testsuite>
</testsuites>

What's wrong here? look at the following line:

<testsuite name="P\Tests\SourceFileTest" file="pest-example/vendor/pestphp/pest/src/Factories/TestCaseFactory.php(185) : eval()'d code" tests="1" assertions="1" errors="0" warnings="0" failures="0" skipped="0" time="0.006614">

and in particular look at the file attribute:

file="/pest-example/vendor/pestphp/pest/src/Factories/TestCaseFactory.php(185) : eval()'d code"

It's not a valid test file.

❗❗

Expected: /pest-example/tests/SourceFileTest.php
Actual: /pest-example/vendor/pestphp/pest/src/Factories/TestCaseFactory.php(185) : eval()'d code

If I run the same test but written in PHPUnit style, I get the correct junit report:

<?xml version="1.0" encoding="UTF-8"?>
<testsuites>
  <testsuite name="" tests="1" assertions="1" errors="0" warnings="0" failures="0" skipped="0" time="0.007011">
    <testsuite name="Test Suite" tests="1" assertions="1" errors="0" warnings="0" failures="0" skipped="0" time="0.007011">
      <testsuite name="PestExample\Test\PhpUnitSourceFileTest" file="/pest-example/tests/PhpUnitSourceFileTest.php" tests="1" assertions="1" errors="0" warnings="0" failures="0" skipped="0" time="0.007011">
        <testcase name="test_it_can_add_two_integers" class="PestExample\Test\PhpUnitSourceFileTest" classname="PestExample.Test.PhpUnitSourceFileTest" file="/pest-example/tests/PhpUnitSourceFileTest.php" line="14" assertions="1" time="0.007011"/>
      </testsuite>
    </testsuite>
  </testsuite>
</testsuites>

Related to and blocks #4

Would be nice to have support for Magento 2 version 2.3.3 and up.

composer require pestphp/pest:0.1.5 on minimum-stability "stable"

Problems

• Installation request for pestphp/pest ^0.1.5 -> satisfiable by pestphp/pest[v0.1.5].
• pestphp/pest v0.1.5 requires nunomaduro/collision ^5.0 -> satisfiable by nunomaduro/collision[v5.0.0-BETA1] but these conflict with your requirements or minimum-stability.

composer require pestphp/pest:0.1.5 on minimum-stability "dev"

Problems

• Can only install one of: sebastian/environment[5.1.0, 3.1.0].
• Can only install one of: sebastian/environment[5.1.0, 3.1.0].
• Can only install one of: sebastian/environment[5.1.0, 3.1.0].
• pestphp/pest v0.1.5 requires sebastian/environment ^5.1 -> satisfiable by sebastian/environment[5.1.0].
• Installation request for pestphp/pest 0.1.5 -> satisfiable by pestphp/pest[v0.1.5].
• Installation request for sebastian/environment (locked at 3.1.0) -> satisfiable by sebastian/environment[3.1.0].

The IDE completion in PHPStorm can be better on closure based tests.

Problem: The $this variable inside closures don't get autocompletion on PHPStorm by default.

it('foo', function () {
    $this->ass // <-- here.
});

Workaround: Add a type hint just before the $this variable.

it('foo', function () {
    /* @var TestCase $this */
    $this->assertFoo // <-- here.
});

Solution: Develop a phpstorm-plugin that can hint phpstorm about this.

Along the lines of describe blocks, curious of the thought process for using only modifier

Example

test('do something here', function(){
  assertTrue(true);
})->only();

Hey!

I'm playing around with Pest (awesome!) and wondering why the uses method don't default to the current directory.

I briefly saw how the magic is made and I think this could be possible.

However, I just noticed that uses(TestCase::class)->in('.) was working.

But the version without in seems more intuitive.

I can definitely submit a PR, if that can helps.

I'm trying to write a plugin and I'm using Pest\Plugin::uses() to add a trait.

When I require the plugin, the test suite stops working alltogether with the following message:

$ vendor/bin/pest
   Pest\Exceptions\InvalidUsesPath
   The path `I:\Code\aurora\vendor\pestphp\pest\src\I:\Code\aurora\tests` is not valid.

I tracked the issue down to src/PendingObjects/UsesCall.php lines 63-68, which are adding the extra path to what is already a full path under Windows.

So atm we have 3 different ways how pest is extensible:

• a file with helper functions loaded with PSR-4 autoloading
• Traits or classes with Plugin::uses and also PSR-4 autoloading
• Composer plugin with interfaces (HandlesArguments & AddsOutput) with auto registration on install

I think we should make it easier for plugin developers to get started. I would suggest to have only the helper functions and the other way through the auto registration.

Otherwise I'm afraid that the plugin docs will get hard to understand.

Problem:
It seems Pest doesn't work well with Psalm.

I didn't know this tool from the Vimeo engineering team, but its domain name was created in February 2019, and it's already got 3K stars of Github.
I'm throwing this issue because it could be interesting to see what would be needed to make Pest & Psalm work well together.

Report from our Discord channel*:

Even though the tests are running, my editor is highlighting errors everywhere in the test code. Psalm thinks the test function does not exist.
Ah man, just saw Pest is using PhpStan instead of Psalm. Psalm is way better.
It is more strict about the types, catching way more type issues, which is sort of the whole point of those things
Psalm also makes it much easier to add advanced information about your code in the docblocks quickly and easily for things you would have to write an entire plugin for in phpstan
I won't use php without Psalm. Using php with Psalm is like already being on php version 10

• Cf Discord, #help, June 2nd, 2020.

We could have an $this->faker instance or something like that or an trait that we can implement using uses(), love to know your ideas on this

Infection is a PHP mutation testing framework based on AST (Abstract Syntax Tree) mutations: https://infection.github.io/guide.

Problem: When running Infection against a test suite written in Pest, Infection will use the phpunit binary instead causing the following exception:

Pest\Exceptions\InvalidPestCommand: Please run `./vendor/bin/pest` instead
  of `/vendor/bin/phpunit`. in /Users/nunomaduro/laravel/vendor/pestphp/pest/
  src/TestSuite.php on line 106

How to fix this issue: Develop a Pest adapter and pull request it to the Infection repository.

Hello!. I've installed Pest in a relative new project, started this month with Laravel 7. Not many packages installed yet and wanted to try Pest in it. Tried to make a simple Login test and it fails:

<?php
// tests/Feature/LoginTest.php
it('redirects back to homepage after login', function() {
//    dd(get_class($this));
    $this->visit('/login')->assertStatus(200);
});

   FAIL  Tests\Feature\LoginTest
  • it redirects back to homepage after login

  ---

  • Tests\Feature\LoginTest > it redirects back to homepage after login
   Error 

  Call to undefined method Tests\Feature\LoginTest::visit()

  at tests/Feature/LoginTest.php:8
      4▕ //uses(\Tests\TestCase::class);
      5▕ 
      6▕ it('redirects back to homepage after login', function() {
      7▕ //    dd(get_class($this));
  ➜   8▕     $this->visit('/login')->assertStatus(200);
      9▕ });
     10▕ 



  Tests:  1 failed
  Time:   0.16s

dd-ing $this returns "P\Tests\Feature\LoginTest"

This plugin would detect memory leaks. I have a prototype of this, but seems that PHP itself leaks memory. I need to take a better look at this.

In an effort to improve Pest and its documentation, we would like to collect your experience trying Pest for the first time.
Remember, there is no wrong answer 🙂

• What problems did you encounter?

• How did you solve them?

• How familiar are you with PHPUnit & testing in general?

To get the ball rolling, I'll share my first roadblock:

• While converting the TALL preset test suite to Pest, I encountered this TestCaseAlreadyInUse exception:

• I figured I was calling my User class from Pest.php, and moved it back into my test file:

use Illuminate\Foundation\Testing\RefreshDatabase;
use Tests\TestCase;
use App\User;

uses(
    RefreshDatabase::class,
    TestCase::class,
    User::class,
)->in('Feature');

• Beginner level: I've just began learning testing in the last 2 years, but it seemed too complicated to integrate on our old projects. I am now starting my first real TDD project with Pest 👌

Your turn now! What troubles did you experience using Pest?

After merging @fetzi's work on plugins. Would be cool to develop a pest-plugin-init that would work the following way:

1. In applications without tests: ./vendor/bin/pest --init
2. Boostraps the tests folder
3. Create a configuration file

It would be nice if Pest were to support Unix-style short syntax for its command-line options:

--coverage would be shortened -c
--min=75 would be shortened -m 75
--group would be shortened -g

Problem 1: Pest adds its options on top of PHPUnit's own options:

-c is mapped to PHPUnit's Read configuration from XML file feature and thus not available.

Problem 2: For the same reason, Pest currently doesn't have its own --help or -h option.

As a user, I would expect to have the --coverage, --group and --min=75 options explained to me when I type pest --help.

Question:

• Are PHPUnit natives options still meant to be used with Pest or should they be replaced/hidden?

PHPUnit supports coverage annotations, both test class wide and per test.

/**
 * @test 
 * @covers App\Model
 */

This will limit coverage calculation to only this class (or method, if specified, etc).

Is it possible to do this in Pest?

Hello 👋

I've encountered a weird "issue" while using a dataset with uppercase values:

->with([
  ['Foo', 'Bar', '[email protected]', LocaleEnum::EN, RoleEnum::ADMINISTRATOR]
])

Test output:

If 'Foo' is given, I'm expecting it to be displayed as 'Foo' not ' foo' 🤔

Thanks for your time! 😄