Test suite should not rely on triggering composer

[clue]

Currently, the test suite uses composer to temporarily install some packages, analyzes the resulting package set and then removes the packages again. This makes the test suite slow to run, dependent on a decent internet connection and introduces unnecessary dependencies.

Afaikt this is only done in order to generate an up-to-date lock file.

Instead, I'd like to propose to commit the resulting lock file (and perhaps hand-tune the expected parameters).

[schmittjoh]

I'd like to keep the downloading at least for Travis, but we could cache the downloaded contents locally. That way they would only be downloaded once (or when you manually deleted the folder) while Travis would still run on the most recent composer.lock version.

[clue]

I'd like to keep the downloading at least for Travis, but we could cache the downloaded contents locally.

Afaict this project doesn't even use travis? :) Anyway, would you care to elaborate on the rational of requiring a fresh lock file? Using a cached version would certainly help, but why require using composer in the first place?

Besides, my initial motivation to suggest this change was that the test suite currently consistently fails to run because it can't resolve the dependencies.

[schmittjoh]

That's a good point :) - I've just enabled Travis - not sure why it wasn't active.

Requiring a fresh lock file just helps us ensure that we still support the most recent composer format. Afaiu your main concern was speed (understandable), but caching the lock file between runs should solve it, no?

[Potherca]

Always requiring the latest composer format does mean that it is possible that (at least for a transgression period) older versions will not be supported... You could use local fixtures and maintain support for a defined format an only have Travis validate that a "fresh" file does not have a different format.

Imho this should be a build step, not something that is validated by a (unit) test.

I guess that the easiest way would be to keep a local definition of the json schema from the composer repo and check that against the file from the vendor directory.

If only I wasn't so damned lazy I would just build this check myself and open a PR :smile: