Two weeks ago I was invited to speak on the 121 Test Automation Day Conference Berlin about one of my most favourite topics – Software Quality in Web Projects.
It really was a nice audience and I received very good feedback on it. The slides can be found here: https://slides.com/carstenwindler/continuous-testing-and-beyond#/.
Looking forward to my next talk, wherever that will be 🙂
The waiting for PhantomJS 2.5 seems to have come to an end – unfortunately, it will most likely never be released.
According to a statement of Vitaly Slobodin, the current maintainer of PhantomJS, the further development has been stopped. This is particular sad as version 2.5 beta has been released already and a lot of effort has been put into this release.
But why? As reason, Vitaly states the release of Headless Chrome with Google Chrome 59. Fair enough, a few developers can’t compete with Google at all.
As a matter of fact, PhantomJS was pretty unique for quite some time. An amazing project which established headless browser testing on wide areas, so it has been a fundamental contribution to the testing world.
I think the actual, long anticipated release of Headless Chrome was just the final the straw that broke the camels back. Since the infamous ticket 546953 it was totally clear that it was worked on it, also conference talks of the developers talking about the technical background came up, so it was just a matter of time since it would show up. It was not really a surprise. So why not stop development of PhantomJS even earlier?
It pretty much feels to me that one of the main potential drawbacks of the Open Source Software movement was the main reason: only a few developers have to deal with the many bug reports and feature request of thousands of users which are all happy to use the tool day by day, but are not willing to contribute or even pay for it. If you can’t make a living from your Open Source project, there will be that one day when it is simply enough. Even the biggest enthusiasts have to pay their bills.
To be honest, over the past years I have been in some sort of Love / Hate relationship with PhantomJS. The many bugs (which are totally normal to happen) combined with the very slow release cycles (which were absolutely annoying, but again understandable) ended up in many, many hours or even days of looking for reasons why that particular test failed only in PhantomJS (e.g. my previous blog post File uploads not working with PhantomJS). On the other hand, I can only express my deepest respect and thankfulness to the developers involved. And yes, I am also one of the thousands of users who used PhantomJS without any contribution.
What will Chrome Headless bring us? I think chances are pretty good that it will be the new standard for Headless testing soon, and this is by no means an offense to the PhantomJS project. There will be a new ecosystem around it, which will make integration of Chrome Headless as easy as for PhantomJS.
On the other hand, we will loose an independent player on the field, and once again Google will gain more power.
However, being responsible for the future wellbeing of the projects I maintain as it is my profession, I will have to adapt to this change. I will have to change the project stacks in order to replace PhantomJS with Headless Chrome very soon. At least not taking it into consideration would be a huge mistake. Still the ecosystem around Chrome Headless as to evolve, but I actually have no doubt it will.
Luckily PhantomJS implemented the Remote WebDriver Wire protocol since version 1.8 (speaking of GhostDriver here, another project from the PhantomJS ecosystem which I didn’t even mention yet), so those projects which were not relying on the PhantomJS API will be lucky.
Just recently, ChromeDriver 2.30 which officially supports Chrome 59 has been released – one concern less!
So far no new maintainer of PhantomJS has been found. The burden might be too heavy.
Just a quick one today: when you struggle with writing Acceptance Tests for file uploads using PhantomJS (will version 2.5 ever come out? *sigh*), here are two possible solutions for you.
The first issue might be that the input field is hidden for obvious reasons. Luckily we can solve this issue without making your designer cry (and we don’t want to do this, don’t we?) by just tweaking the CSS using JavaScript.
In my case, the input field was hidden by using a very low opacity value, so I set it to 1 just before attaching the actual file:
// PhantomJS 2.1 workaround #1:
// Make input[type=file] visible
$I->executeJS(
'document.getElementById(\'input-field\').' .
'setAttribute(\'style\',\'opacity:1\');'
);
$I->attachFile('#input-field', 'test.jpg');
If this solves your problem – great! If not, I got one more.
While the first issue is somewhat understandable … well, maybe …, anyway, I found the second one just by good old trial-and-error: PhantomJS doesn’t like multiple uploads!
Now we don’t want to remove the possibility to upload multiple files just to please PhantomJS, so let’s do another tweak:
// Phantomjs 2.1 workaround #2: // Don't use multiple uploads $I->executeJS( 'document.getElementById(\'input-field\').' . 'removeAttribute(\'multiple\');' );
Of course we can’t test multiple uploads that way, which is a bit sad, but right now I’m afraid we have to live with that.
If you found these two little tips helpful, or if you have another nasty PhantomJS workaround at hand, please drop a comment below!
One new feature of Laravel 5.4 are so called “Automatic Facades”. My colleague was expecting my reaction when he send me the link to the blog entry announcing this feature (I’m not linking it intentionally) with a thievish smile.
So far it was required to add Facade classes in order to make this work. It seems even this little barrier has fallen now.
Laravel’s Facade in my opinion is one of the worst features a PHP framework offers nowadays. After times of Zend Framework 1 and the infamous Registry (I abused it too), when IoC finally arrived in the PHP world, it somehow seemed to me as quite a setback when Laravel became more and more popular with its Facade feature (it’s not even the Facade design pattern anyway).
Here’s why.
Making classes available in the code everywhere is tempting unexperienced (and experienced) developers to use the facade everywhere, without thinking if this might be a good idea or not. I’ve seen things! I even found Facade in configuration files. IN CONFIG FILES WTF!!1
If you don’t pay close attention, your classes soon will violate the single responsibility principle, simply because you don’t really notice how many dependencies you suddenly use.
In my opinion code should be bound as less to the underlying framework as possible. I totally get the advantages of ORMs and such, I’m not opting against packages etc., but binding your code too close to a framework can cause problems if you want to use your business logic over longer terms.
But well, I guess if you are willing to use non-namespaced helper functions everywhere in your code (another Laravel feature I “deeply adore”), you don’t really care about this either.
“But Facades are more testable than traditional static methods!” I hear the Artisans yell. Yeah, sure, that is true.
What a benefit!
It just requires bootstrapping of Laravel for every test, making unit tests significantly slower. Your tests will become more complex and thus require more maintenance, as you will need to mock more dependencies which are all required to make one test work.
Any modern IDE provides Code completion, so I can see in a second which methods a class offers. With Facade, I need an additional package that parses the Facades and generates documentation files that the IDE can parse for the Code completion.
How convenient!
When stepping through the code during debugging it annoys me pretty much to go through the facade over and over again. It’s just so unnecessary…
Probably both IDE and Debuggers are not so commonly used amongst Artisans?
I really don’t get why
Cache::get('key')
is more “expressive” than
$this->cache->get('key')
Somebody needs to explain!
To be fair, even the official Laravel documentation states that Facade should not be used when building a third-party package, and that it bears some of the above mentioned risks. So Taylor is aware of it. But then why is this feature enforced in the first place anyway? I think it’s because Laravel claims to be so “expressive” and “beautiful” in it’s syntax that everybody accepts the downsides.
Decide for yourself if it is worth it.
Probably I’m just missing the point here? Why do you think Laravel’s Facade should be used rather than Dependency Injection?
Say we use a DI container directly, i.e. via functions like get() or make(), how do we achieve proper IDE support? For example I create a class instance the usual way
$server = $this->container->get(Server::class);
and I want to know what methods my Server class provides
$server-> ???
I could use docblocks
/** @var Server $server */ $server = $this->container->get(Server::class);
This works fine in many IDE like PhpStorm:
however the docblock is somehow annoying to me. The IDE *should* really know what class instance the variable $server is, since everything it needs to know is in the class name constant I provided as parameter for the get() function.
There might be a way using the hardly known .phpstorm.meta.php file for PhpStorm, but that one is currently some sort of under construction – at least I couldn’t get it working properly. Hopefully the PhpStorm guys will extend the documentation soon!
Once again, the PHP community provides the solution: the small but pretty cool PhpStorm PHP-DI plugin does exactly what we need! Now PhpStorm knows that $server is an instance of the Server class without me needing to do any further work:
$server = $this
->container
->get('CarstenWindler\ApiGuy\Server');
But really, you shouldn’t do that. Please. Better just forget what I said. Forget it. Begone!
Awesome! Although actually written for the PHP-DI container, it also supports container-interop and even that crapp… I mean lovely but omnipresent Laravel App Facade sort of jun… container… thing.
Well, actually the Typo3 7 LTS versions were available for a couple of months through my Github repositories of cwmobileredirect and cwenvbanner already, however I never found the time to upload them to TER. Finally I found some time to upload it, so here you go:
cwmobileredirect on TER
cwenvbanner on TER
The new versions do not include any new features, I did some cleanup though, so Typo3 4.x is no longer supported. Please just stick with the old versions of the extensions in case you are still using one of these ancient Typo3 installations.
Besides Typo3 7 compatibility and cleanup I spend some time on making them work with a Composer based Typo3 installation (the outcome can be found on Github as well) and Travis CI. Since I only work on these extensions occasionally, this will surely help me in with the Typo3 8 LTS versions (which I hope to get done a bit earlier this time :-)).
End of June this year I had the honor to hold the Opening Keynote at the Clean Code Days 2016 in Munich. Actually my first talk on a Conference ever, I called it “The Lone Stranger, or: Why you can’t establish Clean Code on your own“.
It covers the wide range from how to convince Managers and Co-Developers to start clean coding, over to tips and tools on how to change a legacy project from sloppy code into better and one day maybe even “Clean Code”.
I wasn’t able to watch it in full yet (boy, my voice sucks ;-), but I hope you like it!
PhpStorm comes with a handy phpunit test runner, which lets you execute your tests with just one click. Even better: if a test fails, you can just run that test also with just one click. That’s how I like it.
However I often use the debugger to debug failed tests. This is easy with phpunit and via the command line (see e.g. Remote CLI debugging). But since PhpStorm is obviously not using the command line, we have to pass the information necessary for Xdebug and PhpStorm to initiate the debug session using the Test Runners configuration.
XDEBUG_CONFIG=idekey=PHPSTORM ; PHP_IDE_CONFIG=serverName=local.dev
Needless to mention that the above values need to fit your setup. Most likely your server name will be different, and make sure to check the ide key.
But where to put it? Assuming you already setup your Run/Debug configuration, just open the configuration dialog and put the above environment variables into the “Environment variables” input field. You don’t need to add “export” or anything. Well, just have a look:
Now just place your breakpoints as you need them and start the Run/Debug configuration.
Not many useful PHP books have been published recently (or I haven’t yet discovered them), so I really want to recommend “Modern PHP” by Josh Lockart, another quality product by O’Reilly.
Having only 270 pages, it’s easy and quick to read, and includes a lot of best practices, tips and state-of-the-art tools for writing cool PHP applications. Some topics are covered a bit briefly like e.g. Testing, but the book points you towards the right direction and gives you useful references to read further, if you are interested.
The experienced PHP developer should actually be familiar with most of the topics, so you would probably not learn too much new stuff. Still it gives the good feeling of confirming that you are somewhat up-to-date 🙂
I use Xdebug not only to hunt bugs, but also for every day development work. Of course I also want to use it when I write my Tests.
I one of my current projects we use Codeception for both Unit- and Acceptance tests. Debugging Codeception Unit tests is as easy as for phpUnit, you just have to make sure that the XDEBUG_SESSION is set as described in my post about CLI debugging with Xdebug.
The Acceptance tests I want to debug are basically just testing a REST API, so it’s usually firing HTTP GET/POST requests against various endpoints:
class ApiCest
{
public function testDoStuff(ApiTester $I)
{
$I->sendPOST('/my/api/dostuff');
// testing starts here
$I->seeResponseCodeIs(200);
}
}
In order to debug the actual “dostuff” endpoint, I have to take care of two things: the debug session Cookie and the PhpStorm debug configuration.
The usual way for me to start a PhpStorm session for non-CLI scripts is to enable the “Start Listening for PHP Debug Connections” in PhpStorm and initiate a request with the XDEBUG_SESSION cookie set.
I’m assuming you have PhpStorm and Xdebug set up neat and nicely, as there are enough tutorials about it out there.
This works nicely when I start a debug session using the browser, but now we don’t use a browser and send the requests via HTTP directly (Codeception uses Guzzle for that), so we have to set the Cookie somehow. There are (at least) three ways to do that with Codeception:
$I->setCookie('XDEBUG_SESSION', 'PHPSTORM');
This is described Codeception manual on the PhpBrowser module
Codeception-Remotedebug on Github
This is my preferred way, it’s actually pretty easy to set up, and this way I just send the Cookie all the time.
extensions:
enabled:
- Codeception\Extension\RemoteDebug
config:
Codeception\Extension\RemoteDebug:
sessionName: PHPSTORM
This might cause some headache if you forget about it. When I tried to all of the above ways to set the Cookie, the debug session was always getting stuck, i.e. PhpStorm was not stopping at the breakpoints and rather did – nothing!
By default, PhpStorm is configured to handle 1 debug session at a time. However in my case, I need to handle 2 debug sessions in parallel now – one debug session for the actual Acceptance test, and one for the API.
And that’s it. I hope this will be useful for other Codeception users as well!