How do you organize your test code into modules, classes, and methods to enhance reusability and modularity?

In my experience, To enhance reusability and modularity, I organize test code into modules, classes, and methods. Each module represents a functional area, classes group related test cases, and methods encapsulate specific test scenarios. I use inheritance, composition, parameterization, and clear naming conventions to promote code reuse and readability.

In my opinion, tests should be labeled with TAGs. I do not want to "run all tests in this folder" because I do not want to look at what exactly is in this folder. I want to execute tests by saying, "Collect all tests in all folders with the TAG 'backend-xyz' and run them." Additionally, I like to have a test report afterward where I can quickly see if failed tests share the same TAGs. For example, if all failed tests have the TAG 'frontend-xyz', then I instantly know that there might be something wrong with the 'frontend-xyz.' Using TAGs, I can also do things like "short runs" (skip long-duration tests for fast feedback) or "shuffled runs" (execute collected tests in a random order to detect dependencies between them).

Typically a suite would cover a part of code which could be any of the following: a class, helper, mixin, component, controller and so on. Two strategies of grouping unit test code tend to emerge. It can be found in: 1. in the same subdirectories as the source code, 2. in its own tree of subdirectories. The first approach has test code easy to locate when adding to the existing implementation. It is permitting code duplication though. The second way allows for more flexibility. In fact, the best result is often achieved with a balanced approach. While test code files can correspond to source files, new modules can exist as well. They can store re-usable test code, i.e. stubs, data factories, teardown code and other boilerplate code.

Be careful when using inheritance to keep your code DRY (Don't Repeat Yourself). Instead, follow the "Delegation over Inheritance" principle. Example: Instead of inheriting from the "UtilXYZ" class, create an instance variable of it and call its functions explicitly. This approach makes it much easier to understand and debug your classes afterward. An exception for me would be the inheritance of setup and teardown methods. I personally try to avoid multiple inheritance and deep ancestor chains.

If tests share data, be wary of mutable data. If a test changes the data you might need to reset it before the next test runs. This is easy to overlook and everything might be fine for a while until a new test is added. In contrast, if the data is never changed, this cannot be a problem. Consider running your tests in randomized order to flush out such problems.

If you find yourself writing duplicate test code for tests across applications/codebases, you can even create your own libraries (instead of copy-pasting or doing complex things with Git submodules). This is especially useful for "plumbing code" (i.e. code used to set up tests). You can then use the library and have your test code focus on the real test.