0

Disclaimer: I do know that in an optimal world we only test the publics from an interface. However, in reality, we often have a pre-existent code base that wasn't developed under TDD, hence the need to a more flexible approach.

I'd like to design test methods for an ASPX page (blobb.aspx.cs) and since it's not using an interface to inherit from and there's some logic that can't be refactored out, I have to access and test the protected methods of it. I've done my googlearch and arrived at two different suggestions.

  1. Inherit and test within as shown in this example.
  2. Force access to other assemblies as shown in this example.

The first approach seems to be th emost widely suggested and there are tons of blogs talking about as well as answers on SO recommending it. So there seems to be a concesus on the subject. However, the second approach seems most technically proper and has an immence upvote from the community with the only eyebrowse lifter that it's very sparsely mentioned on the web. I haven't found any comparison putting the two against each other nor any reasoning on which is more appropriate in what circumstances.

Hence, me asking.

Community
  • 1
  • 1
Konrad Viltersten
  • 36,151
  • 76
  • 250
  • 438
  • 1
    AFAIK, `InternalsVisibleToAttribote` doesn't give you access to protected members anyway. – dymanoid Jul 19 '16 at 09:01
  • @dymanoid Oh, what does it do, then? And what about the answer I linked to (number 2)? – Konrad Viltersten Jul 19 '16 at 09:02
  • 1
    Gives access to `internal` methods. So you'd need to change all the `protected` members you want to test to `internal` and that could potentially mess up any inheritance structures in play. – toadflakz Jul 19 '16 at 09:33
  • @toadflakz Actually, I realize I was unclear with my statement. There's no need to **substitute** *protected* for *internal* because there's an access modifier *protected internal*, which (as surprising as it sounds) is [listed by MS as a different one](https://msdn.microsoft.com/en-us/library/ba0a1yw2.aspx) than the other two (although the distinction is extremely slight). – Konrad Viltersten Jul 19 '16 at 15:34

1 Answers1

1

From what I was reading on MSDN it sounded like you could automatically have private accessors or InternalsVisbleTo generated for you

When you create a unit test for an internal method in C# or for a friend method in Microsoft Visual Basic, a dialog box appears that allows you to choose between having your internal methods accessed with the private accessor or with the InternalsVisibleToAttribute.

From: https://msdn.microsoft.com/en-us/library/bb385974(VS.100).aspx

But then I read:

The use of Accessors has been deprecated in Visual Studio 2010 and will not be included in future versions of Visual Studio.

From: https://msdn.microsoft.com/en-us/library/dd293546(v=vs.100).aspx

Obviously, you could still roll your own accessors, but that would be a development effort all on its own. Even auto-generating an inherited class would be a pain. And you'd just be creating a source of meta-bugs.

So it sounds like InternalsVisibleTo is the way to go and maybe you change the the protected methods to "protected internal". That way you can access them without creating another test surface for the meta-bugs to cling to.

Darrel Lee
  • 2,372
  • 22
  • 22