Some years ago, i saw some frameworks like Ruby on Rails trying to put tests folder in the same folder with dev codebase.
What's wrong with this approach ?
- Gemfile is becoming a mess with testing , dev and production dependencies.
- Discourage dependencies de-coupling, which means we're encourage to put everthing in the same place for the ease of "directory traversing"
- The codebase now is easier to "break", because for some reason, both tests code and dev code live in the same place, so they must please each other.
The main disadvantage with this approach, is that: Testers are afraid to write tests ! They're touching the main codebase!
I see the same problem with many frameworks in other languages also.
"Stop putting tests folder in the same codebase with dev folder"
So what does "First class testing" mean ?
Treat your tests folder the same role as dev folder, with its own dependencies, team ownership, development (tests is code), deployment (tests is code, so it could be compiled for deployment)
I'm happy with this approach and i found testing is easier to verify some weird behaviour in the main codebase.
What's your favorite testing strategy ?
Edit: My project structure:
Top comments (9)
Yes, tests need to have their own folder structure for exactly the reasons you mentioned. I also do it that way. But I always have the feeling I am doing it wrong.
One of the most important rules in software design it to put things together that belong together. And a test and the tested class definitely belong together.
Especially, it is no good idea to create separate trees with the same structure because they are hard to maintain.
The same issue occurs in other areas of software development as well, like header and implementation files in C++ and, as Michael wrote, documentation and specifications.
Sure, there are IDEs and other tools that support you in keeping the different structures consistent. Still I can't get rid of the bad feeling.
I guess it's more about convention rather than a rule. Different projects have different convention about project structure.
Maybe "rule" is not a good term. I should have better written "principle". What I actually meant is that whenever you try to structure anything, not only software projects, it is important to keep cohesion strong while keeing coupling weak. Otherwise you will likely end up with an unmaintainable mess. This is a very basic principle and not just a convention.
In that case, DHH (author of RoR) would swear at you that: Look at basic RoR project structure ! It uses Convention over Configuration and it worked well for us over 10 years.
What works in practice is what's right. Not theory.
Agreed. And that's where theories and principles come from. If they no longer match reality, we need to modify or at least extend them. It's called the scientific method.
Unit tests with the code they are testing (I would expect to see
thingy.component.jswiththingy.component.spec.jsin the same directory with the rest of thethingystuff).Integration and end-to-end tests I put first class, though working in Javascript, I tend to share the same
package.jsonacross all of them. If unit tests and end-to-end tests both use Jasmine, I don't want to have that in two differentnode_modules.Can the same be said of documentation for a project?
Sure. Treat the
docsas first-class also. I'm going to post the exact post aboutdocssoon.Thanks for reminding me !
Looking forward to reading it! This was exactly something I was wondering about. I often find it hard deciding when to break up a small test project from notes and testing.