Support abstract methods marked as tests

[tannergooding]

Feature Request

I would like to be able to do the following and have NUnit detect 4 tests.

public abstract class BaseClass
{
    [Test]
    public abstract void MyTest();

    [TestCase(1, 2)]
    public abstract void MyTestCase(int x, int y);

    // etc
}

public class DerivedClass1 : BaseClass
{
    public override void MyTest()
    {
        // Test Logic
    }

    public override void MyTestCase(int x, int y)
    {
        // Test Logic
    }
}

public class DerivedClass2 : BaseClass
{
    public override void MyTest()
    {
        // Test Logic
    }

    public override void MyTestCase(int x, int y)
    {
        // Test Logic
    }
}

Current Behavior

NUnit detects zero tests and doesn't even provide a warning that this is unsupported. The methods in DerivedClass1 and DerivedClass2 need to have the attributes replicated directly to be detected and run.

Alternatives

There are a number of alternatives for a user who is wanting this behavior. For example, they can have the methods in BaseClass be non abstract/virtual and instead call abstract methods.
This is mostly a convenience for the "simple" design when the user has a setup where the attributes are common and should be shared with all derived classes, but the backing logic needs to be customized.

[rprouse]

This has been asked before and I agree it would be useful. If I remember right, there are good reasons it behaves this way, so we'll need to go back and find those reasons so that we can discuss them before approving.

Thanks for your submission, I appreciate it when they are clear, well written and easily reproducible like this.

[jnm2]

I couldn't remember or find previous discussion on this. How should we proceed with discussion?
Do you remember if there was a concern around virtual methods that there wouldn't be with abstract methods?

[stevenaw]

I found a bit of a discussion in #2349 , which was closed due to inactivity. That ticket refers to an original design discussion many years ago which defined the current behaviour. I can't find the original discussion, but @CharliePoole listed a few pros and cons in #2349 (comment). Two considerations in that ticket seem to be around the breaking nature of the change and that the change had (at that time) not been requested before. In addition to this current issue, it looks like a subsequent request to change this was also made in #3274.

One point from Charlie's original discussion that I think is important is that there are several attributes with the current behaviour, and that any change in this area may want to be applied consistently across them. A list of affected attributes provided at the time is outlined in #2349 (comment)