Been googling a bit and haven’t found a good answer.
Should the test folder follow the main folder namespace i.e. tests for a particular class or function is in the same namespace as the class/functionbeing tested or should I keep the tests in separate namespaces depending on need? Is there a best practise?
How do you guys structure the test folder?
By namespace you mean package, I assume?
At least, that’s how I do it. If my class is a.b.c.MyClass, then the unit test is a.b.c.MyClassTest. Makes it easy to find the test.
I’d think that “different source roots, same package, class name suffix” is almost universally accepted.
src/main/scala/my/package/Foo.scala
src/test/scala/my/package/FooTest.scala
First, the test intimately belongs to the class under test, and it’s already nicely separated via the source root, ensuring that no test dependencies can creep into the production class path, so why complicate the namespace any further? Second, you occasionally may want to write tests for package private classes/methods, which wouldn’t be accessible otherwise.
Hello @sangamon,
I totally agree with your answer, It’s preferable to not complicate the packages’ names.
Otherwise, I disagree about the argument where you mention the private classes/methods. In fact, it’s possible to test them using scalatest (with invokePrivate for example) without using the workaround of having them in the same package.
Well… There’s one way, where I put my test where it seems to naturally belong and from there just exercise the class under test like any of its API’s clients would in production. And there’s another way based on symbols and reflection that’s not typesafe, brittle with regards to refactorings, which exercises the class under test differently than any production use. I have a pretty strong bias which of these I’d rather call a workaround. 
Yes, package, too much C# back in the days.
Thank you all for your input. Seems as if keeping the package structure in the test root seems the way to go.