You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When the runner or engine encounters a file name for which we can't run tests, we could obviously just throw an exception and terminate. That's acceptable if the invalid file is referenced on the console runner command-line. It's not OK in several other situations:
When a runner with a continuous UI display (GUI or otherwise) needs to get the information about an invalid file and display it. It can't do that if it terminates.
The invalid file may be nested inside a project containing many other files. We may want to run the tests in the valid files and just display an error for the invalid files.
CURRENT HANDLING
We currently use special drivers in the engine to handle this. They all derive from the abstract class NotRunnableFrameworkDriver. Separate subclasses exist for invalid assemblies and assemblies, which we are skipping because they don't contain any tests.
DRAWBACKS OF THE CURRENT APPROACH
Since we use drivers, we need to create an agent process in many cases. This is costly, since these drivers don't actually execute any code in the tests but merely report back a result in the correct format.
I plan to create a set of NotRunnableTestRunners to replace the drivers. The UnmanagedExecutableTestRunner I created for #1468 will serve as a prototype. Each existing NotRunnableFrameworkDriver, will e sysetmatically replaced by a NotRunnableTestRunner.
These runners (or pseudo-runners) will not follow the ProcessModel and DomainUsage settings used by all runnable test files. They will execute immediately, in process. None of the drivers actually examine the files whose names are passed to them because that has already been done when they are activated. That will remain true for the runners.
BACKGROUND
When the runner or engine encounters a file name for which we can't run tests, we could obviously just throw an exception and terminate. That's acceptable if the invalid file is referenced on the console runner command-line. It's not OK in several other situations:
CURRENT HANDLING
We currently use special drivers in the engine to handle this. They all derive from the abstract class
NotRunnableFrameworkDriver
. Separate subclasses exist for invalid assemblies and assemblies, which we are skipping because they don't contain any tests.DRAWBACKS OF THE CURRENT APPROACH
PLANNED APPROACH
I plan to create a set of
NotRunnableTestRunners
to replace the drivers. TheUnmanagedExecutableTestRunner
I created for #1468 will serve as a prototype. Each existingNotRunnableFrameworkDriver
, will e sysetmatically replaced by aNotRunnableTestRunner
.These runners (or pseudo-runners) will not follow the
ProcessModel
andDomainUsage
settings used by all runnable test files. They will execute immediately, in process. None of the drivers actually examine the files whose names are passed to them because that has already been done when they are activated. That will remain true for the runners.Suggestions or Comments? @nunit
The text was updated successfully, but these errors were encountered: