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.
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.