nunit deploy and accessibility modifiers

[Davis Ford]

Hi, I have a DLL project that implements the Model/Controller part of
MVC, and the client of the DLL would be the View. The interface the
View consumes is the Controller API, and the Model is marked internal,
b/c the View shouldn't need to get at it, but this means I can no
longer test the Model unless my NUnit tests exist inside the DLL
project.

This has the unwanted side-effect of having to deploy nunit.framework,
nunit.core along with the DLL.

If I move the tests out into a separate project, the NUnit tests that
run against the model no longer work b/c the model is not accessible.

Is there some compromise to this solution? Is it possible to fiddle
around with VS2005 DEBUG/RELEASE settings to solve this, or is there
another way?

Thx in advance,
Davis

[Lloyd Dupont]

what about something like:
[assembly: InternalsVisibleTo("TheUnitTestLirary")]?

Alternatively the unit tests could be in the main library but be compiled
only in debug mode
with either of:
#if DEBUG
or
[Conditional("DEBUG")]

"Davis Ford" <da*******@gmail.com> wrote in message
news:11**********************@i40g2000cwc.googlegr oups.com...

Hi, I have a DLL project that implements the Model/Controller part of
MVC, and the client of the DLL would be the View. The interface the
View consumes is the Controller API, and the Model is marked internal,
b/c the View shouldn't need to get at it, but this means I can no
longer test the Model unless my NUnit tests exist inside the DLL
project.

This has the unwanted side-effect of having to deploy nunit.framework,
nunit.core along with the DLL.

If I move the tests out into a separate project, the NUnit tests that
run against the model no longer work b/c the model is not accessible.

Is there some compromise to this solution? Is it possible to fiddle
around with VS2005 DEBUG/RELEASE settings to solve this, or is there
another way?

Thx in advance,
Davis

[Mark Wilden]

"Davis Ford" <da*******@gmail.com> wrote in message
news:11**********************@i40g2000cwc.googlegr oups.com...

Hi, I have a DLL project that implements the Model/Controller part of
MVC, and the client of the DLL would be the View. The interface the
View consumes is the Controller API, and the Model is marked internal,
b/c the View shouldn't need to get at it, but this means I can no
longer test the Model unless my NUnit tests exist inside the DLL
project.

The tests should not be in the same assembly as the Model, because, as you
note, you don't want to have to deploy NUnit.

However, the tests are a client of the model. Unlike with C++, there's no
way to grant access on a class-by-class basis. Hence, you have only once
choice -- make the Model public.

It would be nice if it were impossible then for the View to access the
Model, but there's no way to do that, so you have to live with it. It's not
a big deal in practice - View isn't like a living, breathing voyeur who's
just dying to peak inside your business objects. :)

///ark

[Davis Ford]

Mark Wilden wrote:

"Davis Ford" <da*******@gmail.com> wrote in message
news:11**********************@i40g2000cwc.googlegr oups.com...

Hi, I have a DLL project that implements the Model/Controller part of
MVC, and the client of the DLL would be the View. The interface the
View consumes is the Controller API, and the Model is marked internal,
b/c the View shouldn't need to get at it, but this means I can no
longer test the Model unless my NUnit tests exist inside the DLL
project.

The tests should not be in the same assembly as the Model, because, as you
note, you don't want to have to deploy NUnit.

However, the tests are a client of the model. Unlike with C++, there's no
way to grant access on a class-by-class basis. Hence, you have only once
choice -- make the Model public.

It would be nice if it were impossible then for the View to access the
Model, but there's no way to do that, so you have to live with it. It's not
a big deal in practice - View isn't like a living, breathing voyeur who's
just dying to peak inside your business objects. :)

///ark

I still don't like the idea of making the Model public, simply b/c it
can make for a more confusing API and set of documentation. In some
cases the method called on the Controller is passed through to the same
method on the Model b/c it has no "controller activity" to do. This
can perhaps be confusing -- it is simpler/cleaner if the View looks at
a simple API containing only those things that are relevant to it.

Regards,
Davis

[Mark Wilden]

"Davis Ford" <da*******@gmail.com> wrote in message
news:11*********************@f6g2000cwb.googlegrou ps.com...

I still don't like the idea of making the Model public, simply b/c it
can make for a more confusing API and set of documentation. In some
cases the method called on the Controller is passed through to the same
method on the Model b/c it has no "controller activity" to do. This
can perhaps be confusing -- it is simpler/cleaner if the View looks at
a simple API containing only those things that are relevant to it.

I agree, but I don't see what choice you have.