That was my eventual plan. It's the pattern used, for example in test suite
builders, which responded to CanBuildFrom and BuildFrom.

Generally, I try to discipline myself to _not_ add a pattern that I predict
I will want in the future, because:
1. That future may not come... i.e. the feature or the whole app may be
cancelled.
2. When the future comes, I expect I'll be smarter and may implement the
pattern in a different way than I would today.
3. In the face of uncertainty about _how_ to implement something, doing
nothing generally wins if it's at all possible.

That said, since you are coming up with the same option I repressed, I'd be
willing to do it if we think it justifies itself purely on the basis of the
present (two driver) needs.

Alternatively, I can work toward it when doing the third driver, which will
be the NUnit 2.x driver. That driver will differ vastly from the other two,
including that it will look at more than just the name of the framework. I
would expect that addition to force me (in the TDD sense) to do what you
are suggesting.

So, if I did it now, would I be doing it for the present or the future? Is
there test that would make me do it or is it really just a refactoring to
remove duplication?

Charlie


On Wed, Mar 19, 2014 at 3:50 PM, simoneb <notifications@github.com> wrote:

> In src/nunit.engine/Services/DriverFactory.cs:
>
> > @@ -33,7 +34,22 @@ public class DriverFactory : IDriverFactory, IService
> >
> >          public IFrameworkDriver GetDriver(AppDomain domain, string assemblyPath, IDictionary<string, object> settings)
> >          {
> > -            return new NUnitFrameworkDriver(domain, assemblyPath, settings);
> > +            // Throws if this isn't a managed assembly or if it was built
> > +            // with a later version of the same assembly.
> > +            AssemblyName assemblyName = AssemblyName.GetAssemblyName(assemblyPath);
> > +
> > +            var testAssembly = Assembly.Load(assemblyName);
> > +
> > +            foreach(var refAssembly in testAssembly.GetReferencedAssemblies())
> > +                switch (refAssembly.Name)
> > +                {
> > +                    case "nunit.framework":
>
> I would suggest that the choice of which driver to use is delegated to the
> driver itself. In other words, I would ask the driver if it supports the
> refAssembly and then use the first driver which responds positively. This
> would move the magic strings each in its own driver, which btw already have
> this knowledge because they pass it in the constructor of the
> BaseNUnitFrameworkDriver.
>
> --
> Reply to this email directly or view it on GitHub<https://github.com/nunit/nunit-console/pull/19/files#r10775840>
> .
>