I am a developer, I can read insane arrays containing 6 or 7 nested other arrays (thanks to paranthese matching of my IDE), but I don’t want to. When writing tests (and apps too), I try to apply KISS as much as possible because if your tests are complicated they might as well be faulty which is not acceptable for TDD. Now I think managing nested arrays for Cake Model data can work alright, but recently I wrote a GIF file decoder & encoder in PHP which required tons of nested arrays and fixture data. YAML was *very* helpful throughout the entire process of cataloging a set of images to see if the decoder can decode them successfuly. So regarding the test suite you could leave the choice to the developer on what fixture type they want to use. Inline PHP can be done with a little regex and eval.

The “problem” with fixtures is that they sometimes do not store plain data. Fixtures (as in Railsland) can contain loops or function calls, so in my opinion it is wrong to store fixtures in a data format. MAybe the format shown in the post is not perfect and can be improved, but I think it is the direction to go.

I think the concept of YAML that you do not need an IDE to reasonably edit the files is not really important for developers. I don’t know how you work, but if I write tests, I am always in my IDE.

Well, in Rails you can mix your YAML files with Ruby snippets to allow for dynamic fixtures, so you can do something like (the example is in PHP):

password: <?php echo md5(‘thepassword’); ?>

Regarding your problem with it’s DRY’ness, you could do something like this:

posts_table_definition:
– id
– name
– url

cakephp:
– 1
– CakePHP website
– http://www.cakephp.org

manual:
– 2
– CakePHP manual
– http://manual.cakephp.org

But I don’t even see why you’d want to do that. When you need to change table fields, you can run a quick search & replace, which your IDE should handle, even for YAML, and your done. The entire point of YAML is that it’s not about DRY’ness but about readability for humas, which is exactly what you want when dealing with test data.

Regarding your other issues with it:
- Yes, PHP is more consistent with Cake. But only because Cake goes with Conventions over Configuration, otherwise PHP would maybe never have become the language used for configuration files. But we are not talking about configuration files here, we are talking about Domain data. And data is usally stored in the database when working CakePHP. Since database isn’t the first choice for test fixtures, I think YAML wins over php as a form of data storage.

- Another concept of YAML is, that you don’t *need* an IDE to be reasonably able to edit it. But you do need one for php, so again, in my oppinion YAML wins.

- “YAML looks ugly if you mix it with code”: Your sql database looks ugly when you mix it with code too? Or do you mean putting business logic in your yaml files? I wouldn’t see why that would be needed. Different fixtures, different files.

:id:name:url:

versus

function(){returnarray(,”,”);}

(excluding whitespace). Also note that the PHP version requires the class wrapper and the columns array, neither of which are required for the YAML version.

Lack of IDE support just means you need a better IDE. :)

And I think code tends to look ugly next to YAML, but that is just an aesthetic choice.

Trade-offs, trade-offs, trade-offs. Everything is trade-offs. :)

var $columns = array(‘id’, ‘name’, ‘url’);

DRY was not the only reason I have chosen plain PHP over YAML:
- a PHP solution is more consistent with cake
- there is IDE support for PHP, but not for YAML (thanks to the templates of my IDE I am faster writing a method than a YAML record)
- YAML looks ugly if you mix it with code

Premature optimization is the root of all evil. — Donald Knuth

Not sure I like your approach because there is NO inline documentation. And a change in the table layout will probably require a re-write of every single fixture for that table. Unless you always add columns at the end – which I don’t.