Welkom op julesgraus.nl

14-01-2024

Voorwoord

In dit artikel uit ik een mening die ik misschien niet met jouw deel. Het is prima als je een ander mening en overtuiging hebt. Het is niet mijn doel om iemand van streek te brengen met dit artikel. Als je zelf PEST php wil gebruiken, dan is dat prima. Ik snap dat de maker van PEST Php er behoorlijk wat tijd in heeft gestopt, en dan het product door de tijd wellicht beter zal worden. Wellicht zijn onderstaande argumenten tegen Pest php dan niet meer gegrond. Ik ben niet voor de volle 100% tegen Pest. Maar voordat ik er in elk project mee wil werken, denk ik dat het een en ander verbeterd moet worden.

Waarom je Pest PHP toch beter niet gebruikt. Maar misschien wel in de toekomst.

Aanleiding

Ik besloot in een van mijn privéprojecten Pest PHP te gebruiken. Echter kwam ik er al snel achter, dat dat toch niet zo een goed idee bleek te zijn. Op YouTube zag ik een hele poos geleden een video over Pest PHP. De manier van schrijven stond mij wel aan. Namelijk hier door.

• Je hoeft je test functies immers niet in een class te stoppen die de standaard testcase extend.
• Je hoeft niet iedere keer te beginnen met public function
• Je kan expectations chainen.
• De kortere syntax bespaart tijd.

Migrereren van PHPUnit

Met enthousiasme gebruikte ik de migration tool om van phpunit naar pest over te schakelen met de drift tool. Nog steeds enthousiast kwam ik mijn eerste teleurstelling tegen. Mijn tests waren helemaal niet goed gemigreerd. Mijn IDE toonde op verschillende plekken rode lijntjes onder bepaalde method calls. En gaf aan dat deze methods niet meer gevonden konden worden.

Na ongeveer in verwarring geweest te zijn, snapte ik wat er gebeurde. Enkele van mijn PHPUnit tests extenden niet direct de standaard PHP Unit testcase. Maar er zat een class tussen. Dus niet op deze manier UserTest -> TestCase maar op deze manier UserTest -> HelperTest -> TestCase. De drift tool had dit niet meegenomen. In de migration guide staat deze passage:

While most of your tests should be converted automatically, and you should be able to run them without any issues, there are some cases where you may need to manually convert some of your tests.

Nu vraag je je waarschijnlijk af hoe je dan "manually convert"? Dat staat er niet bij! Success. Hier had ik al de neiging om te reverten naar PHP Unit. Maar, ik besloot toch door te gaan. Nog steeds hopende dat het me veel tijd ging schelen als het uiteindelijk allemaal werkt.

Het onverwachte configuratie bestand

Uiteindelijk zag ik in mn tests map het Pest.php bestand. Als je er even snel naar kijkt. Dan lijkt het op het eerste gezicht of je naar een test kijkt. Het staat immers in de test map, dus zo gek is die aanname niet:

<?php

/*
|--------------------------------------------------------------------------
| Test Case
|--------------------------------------------------------------------------
|
| The closure you provide to your test functions is always bound to a specific PHPUnit test
| case class. By default, that class is "PHPUnit\Framework\TestCase". Of course, you may
| need to change it using the "uses()" function to bind a different classes or traits.
|
*/

uses(
    Tests\TestCase::class,
    // Illuminate\Foundation\Testing\RefreshDatabase::class,
)->in('Feature');

/*
|--------------------------------------------------------------------------
| Expectations
|--------------------------------------------------------------------------
|
| When you're writing tests, you often need to check that values meet certain conditions. The
| "expect()" function gives you access to a set of "expectations" methods that you can use
| to assert different things. Of course, you may extend the Expectation API at any time.
|
*/

expect()->extend('toBeOne', function () {
    return $this->toBe(1);
});

/*
|--------------------------------------------------------------------------
| Functions
|--------------------------------------------------------------------------
|
| While Pest is very powerful out-of-the-box, you may have some testing code specific to your
| project that you don't want to repeat in every file. Here you can also expose helpers as
| global functions to help you to reduce the number of lines of code in your test files.
|
*/

function something()
{
    // ..
}

Waar je naar kijkt, is dus geen test. Je kijkt naar de configuratie van PEST php.

Uses?

Het eerste vage wat je tegenkomt, is de uses functie. Deze doet 2 dingen. Je mag er 1 class in noemen en meerdere traits. Allemaal komma gescheiden. Als je dit doet, verwijst de $this variabele naar de class en traits. Eigenlijk kun je zeggen dat het erop lijkt dat pest php toch een of andere class maakt en deze, de genoemde class en traits respectievelijk extend en used op de een of andere manier.

Waarom ik het vaag noem, is om deze redenen:

• Er wordt hierover niets gezegd in de migration guide. Daardoor lijkt de migratie simpeler dan hij soms is.
• Als je op de Pest PHP website zoekt naar uses zoekt in de zoekbalk, komt deze uses functie niet naar boven.
• De uses functie zou in mijn mening 2 nullable argumenten moeten accepteren. $class en $traits. Het suggereert nu dat je meerdere classes kan meegeven. Maar dan werkt het niet.
• De uses functie is niet gelimiteerd tot het config bestand, je mag hem ook bovenaan in je test zetten. Als je het mij vraagt, scheid je config en test code van elkaar.

Coverage

Laten we het ook nog even hebben over coverage: Pest PHP ondersteunt de phpunit annotations niet volledig. Voor sommige, zoals de dataprovider is er een alternatief. Maar voor de belangrijkste in mijn mening niet. Namelijk @covers Soms vind ik het niet genoeg om enkel alleen de class name in een @covers statement te noemen. Maar ook de method name. Pest PHP ondersteund alleen het coveren van de complete classes, en global functies. En ook dat is niet gedocumenteerd in de handleiding! Voor de volledigheid, je kunt dat bijvoorbeeld zo doen in Pest PHP test()->covers(MyTest::class, 'globalfunction')

Plugin crashes

En als laaste, in een gemiddelde phpstorm sessie, crashed de Pest plugin 16 keer gemiddeld. Met dit soort exceptions:

com.intellij.openapi.diagnostic.RuntimeExceptionWithAttachments: Read access is allowed from inside read-action (see Application.runReadAction()); see https://jb.gg/ij-platform-threading for details
Current thread: Thread[AWT-EventQueue-0,6,main] 485958457 (EventQueue.isDispatchThread()=true)
SystemEventQueueThread: (same)
	at com.intellij.util.concurrency.ThreadingAssertions.createThreadAccessException(ThreadingAssertions.java:149)
	at com.intellij.util.concurrency.ThreadingAssertions.softAssertReadAccess(ThreadingAssertions.java:107)
	at com.intellij.openapi.application.impl.ApplicationImpl.assertReadAccessAllowed(ApplicationImpl.java:1012)
	at com.intellij.psi.impl.source.PsiFileImpl.assertReadAccessAllowed(PsiFileImpl.java:182)
	at com.intellij.psi.impl.source.PsiFileImpl.getStubTree(PsiFileImpl.java:612)
	at com.intellij.psi.impl.source.PsiFileImpl.getGreenStubTree(PsiFileImpl.java:947)
	at com.intellij.psi.impl.source.SpineRef.getGreenStub(SpineRef.java:33)
	at com.intellij.extapi.psi.StubBasedPsiElementBase.getGreenStub(StubBasedPsiElementBase.java:344)
	at com.intellij.extapi.psi.StubBasedPsiElementBase.getParent(StubBasedPsiElementBase.java:309)
	at com.pestphp.pest.PestNamingUtilKt.getPestTestName(PestNamingUtil.kt:145)
	at com.pestphp.pest.PestNamingUtilKt.getPestTestName(PestNamingUtil.kt:55)
	at com.pestphp.pest.goto.PestTestGoToSymbolContributor$PestTestFunctionReference.getPresentation(PestTestGoToSymbolContributor.kt:91)
	at com.intel...

Hopen op verbetering

Stiekem blijf ik hopen dat PEST Php wel echt ooit goed word. Maar voor nu voegt het eigenlijk weinig toe voor mijn gevoel. De twijfel is in ieder geval te groot om PEST Php aan te bevelen. Maar ik vind het totaal niet erg als anderen het gebruiken en als ik met ze mee moet programmeren. In de projecten waar ik nu aan werk. Ga ik lekker door met PHP Unit.