You rock, Daniele!

I've added a custom visual improvement I wanted to add, feel free to implement or reject it :)

https://github.com/tighten/takeout/pull/135/files#r494363191

Nice! Quick visual refinement suggestion:

Custom separator length for each category to Tighten (pun intended) everything up!

$separatorLength = strlen($category) + 1;
$separator = str_repeat('-', $separatorLength);

$option->addStaticItem("{$category}:")
    ->addStaticItem($separator)
    […]

Grouping and iterating is the way to go IMHO 👍

I what I envision, each service should have a category property. Then, we'll only have to iterate through every categories to get the UI we want. (I'm basically describing your code snippet here.)

If you can brings categories to every service that I can then read to sort everything, that would be very welcome indeed! Thanks 😎

PS: That terminal preview is not just a mockup, it's actually a screenshot of a running hacked version of Takeout. I didn't need to tweak the nunomaduro/laravel-console-menu package to do so 🙂

As soon as Takeout integrate a categories concept for its services, I'll gladly leverage it to submit that PR 🙂

I've tried to add the concept of categories to the core of Takeout, but I am not comfortable enough with the codebase. I hope someone else will be able to contribute that!

I can't remember if I already said that, but I feel it's important to keep an easy way for people to contribute to the documentation!

The fact that it's currently as easy as submitting a GitHub PR is a huge plus. That's how I got involved in Pest in the first place. 🙂

Long documentation pages would greatly benefit from a clickable Table of Contents. See Idea 1 in #90

This idea came back to the surface while re-reading the Expectation API page. It lacks an easy to browse overview of all available methods:

Pest Documentation - Expectations VS Laravel Documentation - Eloquent Collections - List of available methods

Shootout to @octoper who is working in the dark to bring this to life! 👍

Thanks for that!

Bear with me here, as this would need serious refactoring and is for now only generating the menu, but here is the raw idea:

public function handle(): void
{
    […]

    $databaseServices = [
        'mariadb' => 'MariaDB',
        'mysql' => 'MySQL',
        'mssql' => 'MS SQL'
    ];

    $searchServices = [
        'meilisearch' => 'MeiliSearch',
        'elasticsearch' => 'ElasticSearch'
    ];

    $option = $this->menu('Services to enable')->setTitleSeparator('=');

    /* displayCategory() private method */
    $option->addStaticItem('Database:')->addStaticItem('---------');

    foreach ($databaseServices as $service => $name) {
        $option->addOption($service, $name);
    }

    $option->addLineBreak('', 1);
    /* End of the displayCategory() private method */

    /* Start of the displayCategory() private method */
    $option->addStaticItem('Search:')->addStaticItem('-------');

    foreach ($searchServices as $service => $name) {
        $option->addOption($service, $name);
    }

    $option->addLineBreak('', 1);
    /* End of the displayCategory() private method */

    $option->setPadding(2, 5)->open();

    if (!$option) {
        return;
    }

    $this->enable($option);
}

Terminal preview:

I'm all for this new command set 👍

takeout add
takeout remove
takeout start
takeout stop

It makes much more sense than the actual, whether or not one is familiar with Docker! That was the main pain point encountered during testing with a developer friend.

Thanks!

I think cli-menu's separators could be a good start:

Extra steps would only be necessary when the service list begins to be too long. The same way multi-steps forms are only relevant in some cases.

Issue:

Takeout currently sorts the services list by alphabetical order. As more and more services will be added to the list, it might become a bit confusing to browse.

Suggestion:

Each service could have a category property, which could be used to at least group similar services.

Examples of categories:

• database
• storage
• search
• cache
• mail

Improvement:

Thetakeout enable command could now have two steps instead of one:

• Select a category of services
• Choose the relevant service in the curated list

WIP

I'm toying with something better to also sort services by category.

Sure!

Importing the workflow in alfred 4 throws error:

"The workflow you are trying to import is invalid."

Changes:

• Official dependencies names displayed (Confusion between MsSql & MySql should now be avoided)
• Line break to separate the exit menu item from the rest
• Padding around the menu to help the text breathe

Preview:

Improvements:

I think the UI would be awesome with better padding around the menu item text.

Thanks 🙂

If I may, my use case for stop:

• I have an old MySQL container only needed when I work on legacy apps.
• A stopped container doesn't consume RAM nor CPU so I can keep it around for a while.
• It's easier to start a stopped container than to spin-up a new one and having to go through port, version & volume configuration again.

• Adding a precision regarding the multiple MySQL containers example: they must not share the same volume
• Fixed PostgreSQL spelling

Good idea!

It would be worth offering all three start, stop & restart commands, in my opinion. I was expecting them and had to resort to native Docker commands instead 🙂

• Small typos fixed.
• The takeout list table now better reflects what's effectively shown in the terminal.

Thanks for this awesome package! 🙂

If you can't install any workflow on your Alfred copy, I think you should contact the Alfred support first. Sorry for not being more helpful, I don't see what's wrong here.

Hope they'll be able to help you 🙂

Hi!

Everything works fine here and on a clean install as well.

Let's try to solve your issue:

• Please click this download link. Don't open it with Archive Utility or similar software, just download it straight to your computer.

• You should end up with a Mojave-Themes-Switcher.alfredworkflow file in your download folder.

• Double click it to install the workflow.

Feel free to take and post screenshots of the steps you took if this doesn't work 🙂

Thanks!

Perfect solution, can't see any drawback 👍 Thanks for that!

No rush! I'm just signaling the issue before I forget 🙃

Enjoy your holidays 👍

@nunomaduro Somehow, this is still not deployed after 20 minutes. Something might be stuck!

This is a draft PR for adding documentation for Drift.

Perfect! I’ll merge it when I get back home 🙂

Thanks 👍

Hope I'm not pushing it, but I had another idea 🙃

I like your idea of putting Drift on the guide section. It would make even more sense if it was right after the PHPUnit guide.

Here is a transition that we could add:

[…] the test now contains only what really matters.

Wouldn't it be cool if you could automatically migrate your PHPUnit tests to Pest? We got you! In the next section, you will learn all about Drift, our experimental migration tool 🔥

Next section: Drift →

Can we move the Drift guide up one line?

The Creating Plugins guide makes for a nice transition to the Plugins section :)

I've installed the Big Sur open beta to work on that issue.

The aforementioned AppleScript doesn't work anymore, so I'll have to adapt it before using it.

Can we extract only the downloads number from the JetBrains website?

If so, we could have a custom design like so: (I would write a text introduction on top of the page, before throwing the cards).

I've reused a "dome badge" CSS class I'm using on my projects to make different logos fit better together. Also, the card is inspired by some TailwindUI components, and the download SVG is from Heroicons 👍

Good idea, let's have separate PRs 👍

Bumps elliptic from 6.5.2 to 6.5.3. <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/indutny/elliptic/commit/8647803dc3d90506aa03021737f7b061ba959ae1"><code>8647803</code></a> 6.5.3</li> <li><a href="https://github.com/indutny/elliptic/commit/856fe4d99fe7b6200556e6400b3bf585b1721bec"><code>856fe4d</code></a> signature: prevent malleability and overflows</li> <li>See full diff in <a href="https://github.com/indutny/elliptic/compare/v6.5.2...v6.5.3">compare view</a></li> </ul> </details> <br />

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
• @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
• @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
• @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
• @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

</details>

Now that we have an official PHPStorm plugin, can we assume all issues listed here are solved?

If so, we could turn the PHPStorm guide into a broader IDE integration guide. We could also link @m1guelpf's https://github.com/m1guelpf/better-pest for VSCode users.

Continuing on: https://github.com/pestphp/pest/issues/86

Do you have a preference, @octoper ?

Here is a summary of the main questions and arguments against Pest being the default Laravel testing tool:

Common questions:

• Will PHPUnit still work?
• Do I have to rewrite my PHPUnit tests?
• Will there be breaking changes in the future forcing me to rewrite my tests?
• Is there any large-size real world project using Pest yet?
• What about edge cases? (I'm thinking of one which will be solved soon, the animation delay/CI compute time issue.)
• Why should I make the switch? What problem does it solve?
• Will Dusk, BrowserKit Testing & Orchestra also move to Pest?
• Why switch to Pest and not to the 7 years old "atoum"?
• Why does this PR removes PHPUnit from composer.json?
• Why does it replaces default test to the Pest syntax?
• What is Pest main advantage over PHPUnit?
• What about IDE integration and ease of use?
• Can the phpstorm/idea test runner run Pest tests?
• Can I still get XML and coverage reports for my CI environment?

Arguments against it:

• Pest is not old enough yet.
• Pest is not stable enough yet.
• Pest ecosystem is not mature enough yet.
• Pest only offers PHPUnit features via a different syntax.
• Pest adds mental overhead to devs switching to Laravel.
• Pest forces devs experienced with PHPUnit to learn a new tool.
• Pest doesn't have enough resources & educational content.
• "Pest ****" will return less Google results than "PHPUnit ***".
• Pest is not the defacto standard tool. PHPUnit is.
• An hybrid test suite with both PHPUnit & Pest is not optimal.
• Pest as the default wouldn't be good for PHPUnit's future.
• Pest will fragment the testing community.
• The syntax is only familiar if you’ve used tools like Mocha or Jest.
• This is change for the sake of change.

Arguments in favor:

• Pest is to PHPUnit what Laravel is to Symfony.
• Pest saves me time debugging tests with the improved output.
• The fluent syntax is easier to newcomers and feels more natural.
• The data provider syntax is great.
• Pest has great syntax, makes it easy to write tests.

Alternatives suggestions for now:

• Make Pest a preset / optional scaffolding.
• Mention Pest in the official documentation.

I've come to the same conclusion not long ago, +1 for npm 👍

I have read-only access on the Pest repo itself though 🙂

Typo.

Just a typo.

Sure!

You are right @nunomaduro, not->toContainAll() is working correctly, thanks to the word all.

I should have mentioned the real issue, not->toHaveKeys():

test('not - fails when at least one key exists')
    ->expect(['a' => 1, 'b', 'c' => 'world'])
    ->not()->toHaveKeys(['hello', 'a'])
    ->throws(ExpectationFailedException::class);

    // An exception should be thrown for 'a'.
    // However it's not the case.

I've been scratching my head around this one and can't find a way to make it work as I intend.

I could rename the expectation to toHaveAllKeys(), so that it matches the actual behaviour, but it doesn't seem ideal.

Writing the tests made me stumble upon a logic pitfall with the not() modifier.

When all values that shouldn't be here exist, the expected exception is thrown:

test('not - fail when all strings exist')
    ->expect('Pest is awesome')
    ->not()->toContainAll(['Pest', 'awesome'])
    ->throws(ExpectationFailedException::class);
    // OK.

However, when only parts of the conditions are met, the exception is not thrown, and the test doesn't fail as it should:

test('not - fail when at least one string exists')
    ->expect('Pest is awesome')
    ->not()->toContainAll(['Pest', 'clever'])
    ->throws(ExpectationFailedException::class);
    // Should fail, but is passing.

The same problem is encountered with toHaveKeys.

I have no clue how to circle around that, any idea?

Of course! Forgot about the tests, I'll get on it 😌

I'm not familiar with doc blocks best practices yet.

I'll commit this change 👍

Adds new expectations:

• toHaveKeys(array $keys)
• toContainAll(array $needles)

Inspired by Freek in a recent livestream: https://youtu.be/KXUVnu-fTIM?t=3625

Thanks 🙂

New PR: https://github.com/pestphp/pest/pull/139

• Streamlined comments
• Removed potential confusion between $value & $this->value: now we use $expected & $this->value

• Streamlined comments.
• Removed potential confusion between $value & $this->value: now we use $expected & $this->value.

Thanks for trying, I'll submit another PR with the proper file, it should be easier 👍

Broken, as in it always displays the same image?

While reviewing the Expectation API for the documentation, I spotted some potential improvements to make it more readable.

However, I have some PHPStan errors I can't seem to get rid of! Any clue about that?

(At first I forgot to update the PHPDoc, but now it's fixed and the tests still fail)

• Streamlined comments.
• Removed potential confusion between $value & $this->value: now we use $expected & $this->value.

I've just merged the documentation, we can always improve it later. But I think I might have hit the trigger too soon.

Should I wait until Pest 0.3 is released? @nunomaduro