A single autoload block cannot say “these classes exist while developing and nowhere else”, so projects either map tests/ alongside src/ and ship it, or leave the suite to require its own fixtures by hand. autoload-dev is the second block, and it is recent enough that a Composer downloaded earlier this year does not know about it — composer self-update before wondering why it is ignored.
{
"require": {
"php": ">=5.3.3",
"monolog/monolog": "1.2.*"
},
"require-dev": {
"phpunit/phpunit": "3.7.*"
},
"autoload": {
"psr-0": { "Catalogue\": "src/" }
},
"autoload-dev": {
"psr-0": { "Catalogue\Test\": "tests/" }
}
}A plain composer install merges both blocks into the generated autoloader; install --no-dev emits only the first, so the production map carries no test classes and nothing under a document root can reach a fixture by name. The wrinkle specific to right now is that vendor/ is committed — the registry is young, the resolver is not something to depend on during a deploy, and putting the directory in the repository is the answer this year. That means the tree that ships is whatever the last person to run install happened to have, so the discipline is to run composer install --no-dev before the commit that updates vendor/, and a plain install afterwards to get the tooling back. Verifying it is wired correctly takes one command: after --no-dev, the test suite should fail to find its own bootstrap. If it still runs, the mapping is in the wrong block.