Reasoning behind public only test classes

[ricky-hartmann-zocdoc]

Hi! 👋

I've noticed that test classes have to be public. I haven't been able to find any articles/references as to why that is. I've previously worked in NUnit and have had some abstract classes that did some initial setup as well as add some initial tests

Example

public class TestHarness<T> {
    protected T _serviceUnderTest;

   public TestHarness() {
      // create some tests to validate things like public functions have test coverage, etc.
   }

   public void Setup() {
        // additional setup steps
        _serviceUnderTest = AutoMock<T>();
   }
}

With the restriction of "public only classes", something like this isn't possible for internal classes and would like to see (if you're open for it) adding support for more than public classes

[bradwilson]

There's a primary reason, and then a secondary result.

The primary reason is (or at least was?) that public reflection is much faster than private reflection.

The secondary result (which would be a dramatic impact to us personally) is that in our acceptance tests, we often define the code we want to validate in a private class and then use our acceptance test helper to run that code. It's not run during the initial discover system because it's private, but our acceptance test helper doesn't care that it's private (which is of course required, since many of these acceptance tests by definition need to fail, because they're used to test failure conditions).

We won't try to run tests from public abstract classes, which is the workaround I'd suggest for your specific case. A class can be marked as abstract even if it doesn't have any abstract members; it just means that it can't be created directly.

[ricky-hartmann-zocdoc]

Oh, what I meant to include in here was our "service under test" is an internal class, so wanting to use this abstract class as a "harness" to configure a bunch of things is no longer possible since we cannot have a public class (required for the runner) that inherits from an abstract class with an internal type as a generic
public class TestClass : TestHarness<SomeInternalClass>

[bradwilson]

Unfortunately there's not much we're able to do here. This isn't something that'll be changing for v3, I'm afraid.

The only other two suggestions I have are:

1. Don't use generics, or
2. Don't use TestHarness as a base class

Sorry!