This project has moved and is read-only. For the latest updates, please go here.

Private CoreAPI interfaces and unit testing

Oct 27, 2011 at 11:02 AM

I have an question about interfaces in NAudio.CoreAudioApi.Interfaces.

I noticed that all the CoreAPI interfaces and enums have no access declaration specified (public/protected/private). That means they are all private. Some are even declared as Internal! Is there any particular reason to avoid public and partial interfaces? Partial interfaces would come in handy for extended functionality.

The reason I am asking is that I have some unit tests which are written on Vannatech.CoreAudio. Now I would like to convert the tests and use NAudio.CoreAudioApi library instead. As mentioned before I am using interfaces for mocking to isolate testing target.

Let me know if there might be an alternative way for unit testing.


Oct 27, 2011 at 11:06 AM

Yes they are internal. You could use the InternalsVisibleTo attribute to enable unit testing. Partial would be very strange, as they are interop interface definitions. They are kept internal simply to keep NAudio's public API as small and straightforward as possible - don't want people to have to unnecessarily wade through hundreds of public classes when trying to work out what they need to use in NAudio.

Oct 27, 2011 at 12:57 PM

Thank you for the answer.

On a second thought about the partial thing, I agree with you, it would not be actually needed.

I just do not completely understand what hundreds of classes you are talking about. Making an interface public does not require change in its implementation. AFAIK. For addition I counted just twelve (main) interfaces that would be useful in unit testing.

However, it is a good idea to keep API small and simple, thus I am not starting arguing here. Could you please provide me some more insight how could I make the NAudio project's interfaces visible for my unit test project? Does it still require to go over all the required interface files and add the InternalsVisibleTo attribute? Do I have to hard code the test project assembly name or is there some other neat way to keep the two project independent of each other?


Oct 27, 2011 at 1:21 PM

InternalsVisibleTo just needs to be in there once (usually put in the AssemblyInfo.cs file) - just search the source code for examples.

Alternatively, you could do a build where they are public.