Simple assertion mechanism on Tests?

[redbeardcreator]

While trying to figure out TestDisableDisplayErrors, I started wondering if there could be an easier way to specify tests. Something along the lines of PHPUnit's assertThat().

I was think something along the lines of (using TestDisableDisplayErrors as an example):

class TestDisableDisplayErrors extends \Psecio\Parse\Test
{
    public function evaluate($node, $file = null)
    {
        return $this->failIf(
            $this->assertNode($node)
              ->isFunction('ini_set')
              ->withStringArg(0, 'display_errors')
              ->withBoolArg(1, true)
              ->orIf()->withStringArgNot(1, "0") // any string but "0"
              ->orIf()->withNumericArgNot(1, 0) // any number but 0
              // The last three might be collapsed into something like
              // ->withArgNot(false)
              // which would check for a falsey value like 0, "0" or false
            );
    }
}

Of course, that's only with a few minutes of thinking on it. I haven't worked out exactly how it would work, except that assertNode() and all the assertion methods return some sort of assertion object that carries a Node object. The failIf() method would then evaluate the final assertion and return true or false based on the results of the assertion.

This is just a thought. There would be a fair bit of work implementing it. But it would make for more readable tests.

It also has the potential to be moved into a separate library usable by other users of PhpParser. Of course, maybe something like this already exists.... I'll have to look.

[redbeardcreator]

It's just an experiment right now, but I've started on TokenMatcher. It can assert whether a PhpParser Node is one of several basic nodes (include statement, assignment, class definition, etc.)

The next step is to implement some of the more complex things mentioned here, and then start going through parse to see what can be used.

[enygma]

Nice! :) looks like a handy tool

[redbeardcreator]

I hope it will be. Should make a lot of the rules in parse easier to understand.

[hanneskod]

Yes, and probably better unit testing of the Matcher itself. The traits we use now really are not unit-tested at all... I like it.

[aik099]

To me writing PHP code that is considered and error or good is clear enough already. What could be improved though is to start using PHPUnit data providers. Right now this does look like data providers, but it isn't.

If data providers would be used, then in case 1 php code out of 10 would fail that won't stop other 9 codes for same rule to be checked anyway.