2

Closed

Allow tests in non-public classes

description

Remove the requirement that a class containing tests be marked public.
  1. It's currently error-prone, as you might forget to mark your test class public and the tests will quietly never run, giving a false sense of security.
  2. You never actually expect someone to consume a test class as a class, outside of the context of a unit testing framework. That is, it's not a public API in the normal sense.
  3. There's a nice (although uncommon) pattern where the unit tests for a class live in a nested class called Test, like this:

    class MyClass
    {
    class Tests
    {
        [Xunit.Fact]
        void ATest()
        {
            //...
        }
    }
    }
Closed May 5, 2013 at 2:19 AM by BradWilson
We have private tests in public classes but we not intend ti have tests in non-public classes.

comments

JayBazuzi wrote Jul 21, 2012 at 2:00 AM

The fix is simple (http://xunit.codeplex.com/SourceControl/network/forks/JayBazuzi/xunit/changeset/ba4da1a8d4f4) but it does not pass xunit's tests. I need someone with a better understanding of the way those tests are written to figure out how to fix them.

bartelink wrote Jul 21, 2012 at 9:21 AM

Dont know if I'd apply 'nice' to the nesting tests 'pattern' :D But it definitely qualifies as a uniquely powerful construct - especially the fact that it can access privates of the nester

But I've been down the road of putting tests into impl assemblies and wont be upvoting...

OTOH, plenty people have been hit by the discoverability bug and that's a better justification. Best remedy - use Red Green Refactor and you'll never fall prey.

bartelink wrote Jul 21, 2012 at 9:22 AM

(I know you understand all the above, but wanted the info to be explicit for people considering voting on this over other issues)

JayBazuzi wrote Jul 22, 2012 at 3:08 AM

Thanks @bartelink. I'll add more:

Usually this change would not affect the way people currently work - it doesn't add additional restrictions or dictate a specific workflow. One exception is the xunit.net project itself, which may depend on this behavior to be able to feed a failing test to itself as a test. Obviously we'll need to find an alternative way to address that need.

It's likely that many folks have already fallen prey to the discoverability issue, and this would be a breaking change for them - running tests that have never run before, and are likely failing. In the long run, that's a good thing.

BradWilson wrote Jul 22, 2012 at 3:44 PM

There's another really strong motivator not to do this (at least exactly as proposed): private reflection can be exceedingly slow. Unnecessarily increasing the # of classes to search through for discovery (used with the GUI runner and the VS2012 runner) is also another great reason not to just do this all the time.

We will consider ways to enable this, but we are unlikely to ever have them on by default. What we can do, though, is make it easy for you to turn them on when you want them on and are willing to pay the price for it.

EyalShilony wrote Aug 10, 2012 at 5:58 AM

This doesn't make sense to me, why would you want to hide your tests? the benefits are extremely low and the cost is just too high to be useful.

This also goes against the assertion of Kent Beck that state that all your unit test should run within 10 min, this is merely a guideline but still such a change will affect the time that it takes your unit tests to run.