The dynamically generated test steps which Pawel introduced in https://chromium.googlesource.com/chromium/tools/build/+/master/scripts/slave/recipe_modules/chromium_tests/steps.py some time ago are a valuable piece of Chromium's testing infrastructure. JSON files in the Chromium workspace control the instantiation of these Test objects, and changes to those JSON files can be sent through tryservers, ensuring they don't break.

Part of the difficulty in maintaining these classes is that there is a split deep in the inheritance hierarchy between tests run locally and tests run on Swarming. (Some waterfall bots, like one-off GPU configurations, do the former.) This came up most recently in  Issue 690085  and sergiyb's https://chromium-review.googlesource.com/445788/ , though it's also come up in earlier bugs like  Issue 649762 ,  Issue 507796 , and others.

One idea to eliminate this split would be to refactor the Test classes into a bunch of handlers, and use composition of these handlers rather than inheritance to express the logic. I think that for a given test type, the particulars of launching the test and the handling of its results should be able to be factored out and shared across the "Local" and "Swarming" variants.

Then, ideally, these two flavors could just be two different instances of the same Test class. One would be configured with an instance of the Swarming handler which knows how to launch all kinds of tests on Swarming, and the other would know how to do the same locally. The Test hierarchy with its many subclasses might be able to be collapsed into one class -- or at least a smaller number than now. This would improve maintainability.