onsi
commented
5 months ago hey there - not antithetical at all to Ginkgo - it it is pushing against the grain for Go. There are some projects that organize their test suites into multiple subfolders that are imported by the central suite. These tend to be massive integration tests where the tests are better organized by being split up into subpackages.
My sense you are trying to do something different: you still want your tests and your code to live in the same folder but rather than have one suite per folder you want a central suite that imports all the tests form all the subfolders. This is tricky because Go won’t let you import test packages. So your test code ends up in the same package as your production code. Perhaps there’s some sort of build tag approach that can work around this for you. You’d still need to maintain the list of imports in the central suite. All-in-all it’s just more boilerplate but of a different variety.
maguro
Admittedly, what I'm about to ask may already be available or may be antithetical to Ginkgo philosophy.
I have a fair sized project with numerous packages. Some packages are small. It's quite tedious to create a new suite in every package and seems a bit boilerplatey. It would be nice to be able to add some kind of config that would recurse subdirectories.