Add helper debugging/rendering function for (unit) tests

[oliverklee]

One big hurdle for adding more tests and for refactoring the existing tests is that we currently cannot check easily what the result of parsing some CSS is. I've thought about how we could improve this.

At the moment, we either check what render() returns (which also tests the rendering code and is dependent on the passed output format), or we do a big salad of multiple assertions, including multiple assertInstanceOf calls for the subject's children..

I'd like to make this easier. For this, I suggest we add an @internal method debugForTesting() (suggestions for a better name are welcome) and add it to the CSSElement (or Renderable) interface.

This method returns an object's class, its relevant data and recursively its children.

The return value is an array as this avoids the problem of multiline strings and long lines that strings have. Also, PHPUnit is quite good at displaying differences in arrays in a readable manner.

For example, the multi-assertion test then could work on an array like this instead (manually written, not tested):

[
  'class' => `CSSFunction` // not the full class in order to improve readability
  'name' => 'max',
  'arguments' => [
    0 => [
      'class' => 'Size',
      'size' => 300.0,
      'unit' => 'px',
      'isColorComponent' => false,
    ],
  ],
];

Unlike var_export, this returned representation can hide some irrelevant internal details and shorten the output.

WDYT, @sabberworm, @JakeQZ?

[JakeQZ]

I think this would

1. work
2. not be too onerous to implement
3. solve the problem it's intending to solve

So it gets my vote.

I suggest we add an @internal method debugForTesting() (suggestions for a better name are welcome)

I'd prefer something like getRepresentation() or getArrayRepresentation(). Probably the latter: it says what it does. Yes to @internal.

add it to the CSSElement (or Renderable) interface.

I think Renderable because CSSElement does not (currently) include statement-only at-rules.

It could be initially added to the interface, with implementing classes throwing a NotImplemented exception (or suchlike). There are probably not that many classes to put the placeholder in, as there are quite a few extended classes that will inherit it. Then we can gradually provide the implementations as we add or refactor the tests.

[
  'class' => `CSSFunction` // not the full class in order to improve readability
  'name' => 'max',
  'arguments' => [
    0 => [
      'class' => 'Size',
      'size' => 300.0,
      'unit' => 'px',
      'isColorComponent' => false,
    ],
  ],
];

This looks perfect for quickly digging into the results of the parsing for testing.

not the full class in order to improve readability

Not just readability. It may make it easier to test for a class name without caring about its namespace.

Unlike var_export,

That returns a string (which is not good for testing, as pointed out in the OP). We're talking about returning an array here.

this returned representation

getArrayRepresentation() I think...

[oliverklee]

Thanks for your thoughts! I've created #1440 for this.