Proxy test class approach to allow covering legacy code with unit tests
public class MyService
{
    public bool Execute()
    {
        return _newMethod() &amp;&amp; _legacyMethod();
    }

    protected virtual bool _newMethod()
    {
        // some business logics

        return true;
    }

    protected virtual bool _legacyMethod()
    {
        // hundreds of lines of code

        return false;
    }
}



You abuse inheritance for testing purposes instead of splitting it up in two classes - one for each service. The current solution also violates the Open/Closed Principle. If you wanted to add another service or logic later you couldn't do it without modifying this god-service.

Virtual/abstract methods should have some purpose and be overriden in a concrete implementation and not used as workaround for testing.

You could improve it by either implementing the decorator pattern or using inheritance correctly. Here are two examples.



Decorator

I find the decorator pattern would be a better choice here. With a decorator you would define an interface like

interface IService
{
    bool Execute();
}


and implement it in two classes. One for the legacy service:

public class MyLegacyService : IService
{
    public bool Execute()
    {
        // hundreds of lines of code
    }
}


and one for the new service:

public class MyNewService : IService
{
    private readonly IService _service;
    public MyNewService(IService service) 
    {
        _service = service;
    }

    public bool Execute()
    {
        return ExecuteInternal() &amp;&amp; _service.Execute();
    }

    private bool ExecuteInternal()
    {
        ..
    }
}


This has the advantage that you can provide any IService to the decorator and test the new logic independently. You can easily create a test-service to fake the legacy one.



Inheritance

If you want to do it with inheritance then the new service should be derived from the legacy service that is derived from an abstract base service.

The overridable method should then be called ExecuteCore. The base service just calles the core method:

public abstract class MyService
{
    public bool Execute()
    {
        return ExecuteCore();
    }

    protected abstract bool ExecuteCore();
}


The legacy-service implements the core method:

public class MyLegacyService : MyService
{
    protected override bool ExecuteCore()
    {
        // hundreds of lines of code

        return false;
    }
}


and the new-service implements it in its own way and using its base class core method:

public class MyNewService : MyLegacyService
{
    protected override bool ExecuteCore()
    {
        // some new business logics

        return newResult &amp;&amp; base.ExecuteCore();
    }
}


This will be a little bit harder to test as the new-service depends on the legacy one so you would need to stub it in tests. Nothing impossible but more work then with the decorator.