Test support classes

[TastyPi]

In our (currently custom non-packs-rails but hoping to migrate) setup, we define test support classes for a package in a testing directory, e.g. packs/foo/testing/foo/test_helpers.rb. However, some of these we want to be usable by packages that depend on it, but currently that would violate privacy checks. Obviously we don't want it under app/public since it shouldn't be loaded in the real environment, but there currently isn't a way to support this.

Is this a situation packwerk-extensions would consider supporting? Or is there a better way to set up something like this?

[TastyPi]

I think this might be doable with architecture layers.

Suppose we have two layers test and app (app could be multiple layers, but for this purpose it shouldn't matter). Then app packages can't depend on test packages, but test packages can depend on each other. packs/foo/testing can then be turned into a package in the test layer and have packs/foo/testing/app/public for its publicly accessible classes (or just disable privacy checks for it since it's not such a big deal for test stuff).

The only issue I can think of for this is packs-rails currently loads all packs, but for tests we wouldn't want to load packages in the test layer. I'll start a discussion there for how to resolve it, but I think I can make this work for my custom non-packs-rails setup.

[alexevanczuk]

Hey @TastyPi I think there might be a couple of paths forward for you here without needing to add additional behavior/complexity.

1. I think the option with the ideal tradeoffs might be close to what you suggest. Instead of having to change what packages are loaded, you could have your pack be packs/foo_test_helpers and define the public_path as packs/foo_test_helpers/spec/public. I believe that would work for you and would allow you to have a package that could have no production code -- only public test helpers.
2. Another option that is less ideal would be to have your test helpers be a gem. This is likely not practical if your test helpers are entangled with the rest of your application ncode.
3. Another option which is a but more nuclear would be to have packwerk ignore your spec directories. This is actually what we (temporarily) do at Gusto to focus on production dependencies and APIs, but of course comes with heavy trade offs.

[TastyPi]

Ooh 1 is pretty close to what I would like. I think it would be cleaner as a nested packs/foo/testing package instead of a sibling, but then defining everything in a subdirectory that Rails won't load is
a clever workaround. It's not the perfect-world cleanest solution IMO, ideally the subdirectory wouldn't be needed, but short of adding new features to packwerk-extensions and/or packs-rails I think it's the best one.

The only potential issue I can think of is the test package can't access private members in the main class, which I can see being potentially useful. It's not an issue I've run into yet (plus my earlier suggestion would have the same problem) but it's probably something someone will want at some point.