I think that the friendly assembly approach that you are investigating would
be better, as it would not require a recompile. It would, however, require
generating of keys and signing of assemblies.

On 10/14/07, Evan Worley <[EMAIL PROTECTED]> wrote:
>
> We have the same problem with NMaven testing, where we can't test non
> public
> classes due to dll visibility.  One solution we were thinking of is adding
> friendly dll support to NMaven, then we could have the test assembly be
> friends with the assembly that it's testing.  The second approach would be
> a
> compile all of the source into the test artifact, which is the option you
> listed above.
>
> Which do you think is a better approach?
>
> -Evan
>
> On 10/12/07, Shane Isbell <[EMAIL PROTECTED]> wrote:
> >
> > I was recently working on NUnit tests and I found the current method of
> > how
> > NMaven handles unit testing inadequete. The problem occurs because C#'s
> > protected method is accessible only within the defining class and
> > its derived classes, unlike Java which includes package level access.
> > NMaven
> > currently compiles the test and main artifacts into separate assemblies,
> > so
> > I also can't test an internal method either. This leaves the ability of
> > only
> > testing public methods, which are a little too coarse grained for what I
> > need. One option that I am considering is to 1) compile main artifact,;
> 2)
> > compile test artifact, which includes both main and test classes. This
> > would
> > require compiling the main classes twice but would allow the testing of
> > internal methods. I am not sure how people are building
> > their .NET applications or whether this option would cause performance
> > problems. Thoughts?
> >
> > Shane
> >
>

Reply via email to