RuntimeFramework was originally created for use in a single-threaded environment. The introduction of parallel execution and especially parallel loading of tests has exposed some weaknesses. Additionally, the class serves a number of disparate functions. Simplifying and otherwise refactoring it will allow us to move forward with pluggable agents, which is why this issue is a part of #909.
Ideally, we should remove all knowledge of the environment from RuntimeFramework. An instance of RuntimeFramework does
not need to know, for example, if it is available on the current system. In the present architecture, that's really the job of the RuntimeFrameworkService. Other functions may actually belong in TestAgency.
All the static properties of RuntimeFramework need to be examined for thread-safety, particularly CurrentFramework
and AvailableFrameworks. The latter is preventing implementation of parallel loading. We may be able to move all this functionality to services or utility classes eliminating the use of public static properties here.
Although all of the above is essentially refactoring, I'm treating this as an enhancement since it enables us to move ahead on new features, which are otherwise blocked.
RuntimeFramework was originally created for use in a single-threaded environment. The introduction of parallel execution and especially parallel loading of tests has exposed some weaknesses. Additionally, the class serves a number of disparate functions. Simplifying and otherwise refactoring it will allow us to move forward with pluggable agents, which is why this issue is a part of #909.
Ideally, we should remove all knowledge of the environment from RuntimeFramework. An instance of RuntimeFramework does
not need to know, for example, if it is available on the current system. In the present architecture, that's really the job of the RuntimeFrameworkService. Other functions may actually belong in TestAgency.
All the static properties of RuntimeFramework need to be examined for thread-safety, particularly CurrentFramework
and AvailableFrameworks. The latter is preventing implementation of parallel loading. We may be able to move all this functionality to services or utility classes eliminating the use of public static properties here.
Although all of the above is essentially refactoring, I'm treating this as an enhancement since it enables us to move ahead on new features, which are otherwise blocked.