Reverting the removal of the tests via .gitattributes

[fabpot]

I think that it is not worth removing the tests classes from archives via the .gitattributes file. The more I think about it, the more I think that the benefits are really small and the drawbacks quite huge:

• people use some of our test classes in their own tests (we have already moved some of them to a Test/ directory and that helps bu I fear that many more will need to be moved -- see https://twitter.com/huizendveld/status/288331330998116352 for an example);
• people like to have a look at the tests to understand how the code works;
• when working on a patch locally on a project, there is no way to run the unit tests to check that everything still work as expected.

I would like to revert this change. Opinions?

[fabpot]

Original pull request: #5674

[fabpot]

And the issue that started it: #6047

[clemherreman]

Same as @marijn, tests are part of the documentation, and have proved more than useful to understand how internals are working. Also I like to run the tests when putting my application on production, just to ensure that my server environnement doesn't break them.

[marekkalnik]

I totally support this. Moreover I think that the test base of symfony is great and we need to encourage people to learn from it rather than hiding it. 👍

[igorw]

To clarify the intent of the original PR: The idea is make the stable, zipped packages optimized for deployment. That means stripping out things like docs and tests that are not needed in production. When this is applied on a large scale, the savings are significant.

Of course stable packages are also used in development, and as such having the documentation present can be very useful.

For the record, I have no problem reverting this. Stable packages != production; stripping out useless things in the deployment process is a sane approach. The fact that composer caches packages locally also helps for speed and bandwidth.

👍

[Seldaek]

I tend to agree it probably causes more pain than good. I fixed composer docs to avoid promoting the practice, because I have seen it spread quite a bit lately composer/composer@bf32869

@fabpot - I think it's all about the target audience. If you are deploying a project, the tests are not necessary. if you are working in a development environment, then you certainly want the tests but you'd get them anyway with Composer which you'd sure be using when developing a project...

Thinking some more, when you have to package a large project it's usually necessary do some assembly and packaging tasks anyhow, so it probably doesn't matter either way.

If tests are considered part of the documentation, then +1 for keeping them. What consumers do downstream when packaging their final products is their own prerogative.

+1 for reverting the PR.

[acasademont]

+1 for reverting this, I look a lot at the tests to see how the code works, not everything is in the docs!

[Seldaek]

One thing worth noting is that test helper classes and such that are
meant to be used by other people should really be moved to a Test/
namespace ideally, to clearly separate public API from internal tests.