NUnit Tests

[Shane Isbell <sh...@gmail.com>]

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

Re: NUnit Tests

[Shane Isbell <sh...@gmail.com>]

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 <ev...@gmail.com> 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 <sh...@gmail.com> 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
> >
>

Re: NUnit Tests

[Evan Worley <ev...@gmail.com>]

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 <sh...@gmail.com> 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
>