Assume a module A, and a testing module for it, T.
I would like to decide which of them should be the sub module of the other.
Intuitively, it would make sense to me to make T a sub module of A, because it has no meaning on its own.
However, I read for example here that
... if the technological context allows for packaging and formal dependency management, you should absolutely go this route instead
Please assume we don't have the capacity right now to set up a packaging pipeline, thus need to use sub modules.
By that rationale, it would make sense to treat A as a package, and "install" it for T, which would mean A is actually a sub module of T.
This is confusing to me, and I would like to know the best practice for this use case, and preferably also thumb rules on how to decide on the main question of "what is a sub module of what".
You mainly use submodules to reach a very high control over your dependencies. Considering the case of A and T, A should definitely be the submodule because it is a dependency of T. It is more likely that you want to stick with A as a submodule, so that your testing project T targets a specific version of A.
Moreover, it feels more natural to me if my project A is a submodule, so a dependency, of many other projects: in this way each of them can pull the version of A they are compatible with.
Last but not least, imagine that you want to restart from zero the testing project T: if A is a submodule, you can destroy T without worrying of anything. Instead, if A has T as a submodule, you need to take care of that and redo the linking with the new testing project.
About the thumb rule, here is MINE: if A depends on B, B becomes the submodule. Following this rule, the dependency can be developped separately.