The HHVM support is most exciting for myself. I've moved production websites and personal projects all over to nginx + HHVM, and I've not run into any issues since the end of last year.
Now, all I want is Facebook's "Hack" language to be formally documented. My personal tests show that the optional gradual H-M typing + HHVM's speed + PHP's benefits === Awesome. PHP has come a long way in the past few years.
[0] http://tester.nette.org/ [1] https://github.com/nette/tester
Part 1: http://www.sitepoint.com/hhvm-hack-part-1/
Part 2: http://www.sitepoint.com/look-hack-php-replacement-hhvm/
Would be great if Facebook would publish more official information.
http://phpunit.de/manual/3.7/en/writing-tests-for-phpunit.ht....
Which is basically turning them into AssertTag calls behind the scenes, which is good as they can be cumbersome to write if not very simple.
The main problem I had with it was the poor error messages it provides on failure (basically "false != true" rather than printing out what it was looking for and what it had found to provide context).
It doesn't look like Nette is going to give any better error messages since it's just passing true or false into a simple Assert.
$this->assertTrue($something, '$something called from WhateverClass returned false')Failed asserting that 'foobar' contains "baz".
If that string "foobar" was generated by your programming then seeing it in that message might be all you need to diagnose the problem, maybe it was just a typo, maybe there's several words missing, whatever tyhe problem is this gives you vital context
If it just said "assertion failed" or "true != false" or even a witty message written by hand with no actual knowledge of what has gone wrong in this particulainstance you'd have to spend time establishing that the string got as far as the test and what it contained.
Rather than typing out a message each time you can even write your own assertions that do it for you based on the values you pass in.
You also get a chance to document it with the function and class name, which again can be automatically shown, e.g WhateverTest::
assert($condition);
It's useless.
What happened to all those people proud of PHP's principles? "Shared nothing", remember? Why on earth would your tests share resources and state? This is not Java. It's PHP.
Look at PHP's own tests: PHPT files. They're simple files containing code to setup a test, and the result of a test.
How tests run, well, in a nutshell:
foreach (glob('/tests/*' as $test)) exec('php ' . $test);
Then you check the logs. You can have your little pretty log formatted if you want, but it's not that important:
- If there's stuff in the log, your test failed, you go check why.
- If there's no stuff in the log, you're good to go.
It can catch output, exceptions, even fatal errors. Can PHPUnit catch fatal errors? You need to use its "process isolation features", which is just reinventing the wheel by doing... what I just did in that one-liner above. Well I did it! Process isolation! And I didn't need PHPUnit to do it.
A lot of those "modern PHP" libraries are basically a masochistic exercise in copying designs that make sense in Java into PHP where they make no sense.
PHPT style tests wouldn't make sense in Java. And Java style Unit test frameworks make no sense in PHP.
However all those blindly supporting this, can please continue to waste their time, for the benefit of making sure they're buzzword compliant & in sync with groupthink.
"I write my mocks and fixtures in PHPUnit. Oh yeah it has all the latest assertions, like you can assert XML using CSS selectors". I can almost hear the collective taps on my back just saying this out loud.
> How tests run, well, in a nutshell:
> foreach (glob('/tests/*' as $test)) exec('php ' . $test);
This fails your own litmus test. The PHPT runner that ships with PHP is actually thousands of lines long: https://github.com/php/php-src/blob/7b7d2952a606fba6a5e21998...
Keep in mind that PHPT files have to be parsed in userland. The runner has to pull out the --TEST-- section from each file, write it to a temp file and then execute the temp file in a separate PHP process. It's actually an incredibly slow way to test your code. I have test suites where thousands of PHPUnit tests execute an order of magnitude faster than dozens of PHPT files.
> "Oh yeah it has all the latest assertions, like you can assert XML using CSS selectors".
The value of PHPUnit isn't really the assertions. It's true that most of the assertions can be replaced with a single line of code. The main exception is assertEquals which requires some special consideration for recursive objects, canonicalization, floating points, etc.
The biggest selling point for my team is the ecosystem. PHPUnit integrates with a number of IDEs, continuous integration platforms, ticketing systems, profiling tools, code coverage tools, code quality tools, etc.