Add tests
Closed this issue · 15 comments
Travis is run, but there are no tests :(
Would you care for that?
Of course there are tests, maybe it's an issue with your migration to PSR-4?
Oh, I see. They are in /src, where is usually the code itself only. Why they are there?
Would you care for moving them to more standard /tests directory?
If you look at existing Symfony code, then src/.../Tests is perfectly standard (note that the parent directories are missing because of PSR-4):
Symfony has not standard repository composition, since it uses monorepo with aim to distribute code effectively - it creates very bare and raw repository. Same with Laravel.
These repositories made it the cleanest way with /src and /tests directories:
- https://github.com/nette/di
- https://github.com/thephpleague/flysystem
- https://github.com/doctrine/doctrine2
My 2nd argument is readability:
/src
/tests
vs.
/src
Which package has higher probability of tests?
Not source, not tests should be Googled manually. IMO they should be in root so user can immidiatelly see.
I saw many repository with .travis.yml and with no tests, so this this file is not 100 % indication of tests.
In my opinion Tests are part of the code, so they should be in the source directory. Taking Doctrine as an example doesn't really work, since they not even use a /src directory, but /lib like back in the 90s ;)
In my projects, I'm actually using /tests for functional and acceptance tests. Unit Tests are part of the code and should not be kept external. Also I want to keep the Symfony standard. So refactoring is not an option at the moment, especially since I would work against my goals with that (namely reminding my developers to write unit tests).
I'm trying to understand your reasons, so please excuse, if I write too much about this topic. I want to understand how people think while creating and maintaining open-source, what are their base source of knowledge and motivation to make decisions they make. Please tell if I push some topic too hard or is uncomfortable in some way. Also if you prefer some other direction or how this might be useful to you. I'm learning right know. Thank you :)
Unit Tests are part of the code and should not be kept external.
I never heard that. Why so?
I've seen only repositories storing every kind of tests in standalone directory. /src/Tests or /tests. Never on 2 different places.
Also I want to keep the Symfony standard.
Keep in mind that it it MONOREPO standard, and very old one, that produces less useful SINGLE REPOS - this one. Symfony structure was created as easy to maintain to 1 person and most importantly, with no previous examples to learn mistakes from. Taking standard from legacy though still maintainable repository, also with different structure and purpose, might create much miss understanding while scanning repo for the first time.
Creating good MONOREPO that creates good SINGLE REPOS is quite difficult. I did a small research on that topic on Github and I'm trying to do my best using best of both worlds in Symplify\Symplify, that splits to independent and useful SINGLE REPOS. Feel free to check it to inspire.
Why do you want to keep this same as Symfony? I mean what advantages do you see in that?
Seems like you got me wrong. My tests are in /src/Tests (PSR-4) or /src/[Namespace]/Tests (PSR-0) - you can easily see that on GitHub. That works for me and many other projects so I see no value (other than confusion) to move existing unit tests (that are just PHP classes like all my other PHP classes) into a /tests/ directory that doesn't indicate a clear namespace and requires an extra entry for autoloading (/src/... already is in the autoloader config), thus increasing complexity without benefit. Honestly, my development team never had problems finding the unit tests in /src/Tests. It simply works very well for us like it is.
I'm not telling your team should argue with you. If location of /tests has aim to keep your open-source project easy to understand for your team, then I please close this issue. My point is not to argue about your team, because I don't know it and I don't work with you. I can only give you point of view from end-user of your package. Nothing more.
...you can easily see that on GitHub.
Actually, I don't. That's why I've created the issue and references some good examples in previous comment.
This is what I see:
I'm telling this is more confusing than is has to be and could be done better for first reader.
Also another drawback of this architecture is that, when I install this package, all tests are downloaded. Increasing downloaded data (slows down CI) and slowing down composer autoloading (slows down in dev and production).
Last point, project architecture has different needs than package architecture.
With the same reason, you could put controllers and models in different main directories (which, actually Zend Framework 1 did and it was a bad idea). Of course the tests are downloaded with every copy of your library, since they serve as the best documentation you can get. Concerning performance: Yes, that might be a valid point, but IMHO fighting complexity and always have the tests available as an important part of your code is more important. I would argue that the performance impact is not measurable and adding bloated frameworks to your project (which is a big but sad trend) has a much bigger impact on performance. Basically every regular Symfony Standard project is already doomed in terms of performance and nobody does a damn thing about it ;) If you check out my Silex-based framework Symlex, you will notice that lean code and performance is my number one priority. Putting unit tests in a directory outside of src/ is really the last thing that I would optimize in practice. Missing tests are way worse for performance, because you can not refactor properly. Productivity also decreases because you might have to look up the tests in the right version that matches your code manually, if they are not part of the library that's installed with composer (see Doctrine). That's why test classes are number one citizens for me, that sit in the same directory as the rest of my code. It's philosophy at the end of the day.
Most of those arguments are opinionated, so I agree we have different point of view on this.
Also most of those issues you mention could be solved by monorepo approach. I recommend at least trying it out, to know how it helps you and how not.
Thanks for sharing your points of view. It helps me a lot to process better argumentation.
Yes, you can do it both ways and I tried both options in the past (I'm in the software business since the 90s). I can not point out enough how important it is to tell developers, that unit tests are part of the code and not something you put later in some other directory. However I'm confused as you mention monorepo - that usually means you put more than one project in your (git/svn) repository. How is that related to the path of the unit test directory?
BTW, when working with svn, most repositories were "monorepos". The trend of separate repos for each project and sub-project came up with GitHub I'd say. People started using submodules, it was cool to fork foreign repos and package managers started evolving, serving ever smaller and smaller pieces of code as a "library". So repositories became small and specialized. It's like in the
fashion industry, where old trends are popping up after a while and people think it's new. I'm doing this for too long now to feel the fascination...
How is that related to the path of the unit test directory?
Since you referenced Symfony repo, it influences the structure. See bellow.
I recommend exploring Symfony, Laravel, Sylius and Elcodi monorepos to get some idea. I did my research on them.
Also inspired by this: https://twitter.com/thedotpost/status/740907256150122496
I don't agree with directory structure, but I do with architecture.