Structuring a solution / projects.

[JohnGoogle]

Hi,

I'm new to Visual C# and I am looking for guidance with structuring
projects.

I am wanting to develop a DLL assembly which will contain all my common
classes which will be used by various projects. During development of
this DLL assembly I have decided to have a second project which will be
a console application whose entire job is to run code to test the
classes to iron out bugs etc.



I have structured this in the following way:


A. I have a solution called XYZCommon (where XYZ is the Company Name).

B. This solution has two projects. Project 1 is called XYZCommon and
will create the DLL assembly. Project 2 is called XYZCommonTest which
is a console application. This will contain the code to test the
classes in XYZCommon.

C. Project XYZCommonTest is set as the Startup Project for the
solution. It also references project XYZCommon.

D. Project XYZCommonTest has multiple 'static void Main(string[] args)'
entry points in different classes. Each entry point will run a test for
the corresponding class in XYZCommon.

E. Before I run each test I set the required entry point as the Startup
Object property in project XYZCommonTest's project property page.


This set up is allowing me to edit and test each class as I go within a
single solution. Is this a sensible way to develop and test a DLL
assembly? What do other people do?


Thanks in advance for any advice!

 

[PS]

Hi,

I'm new to Visual C# and I am looking for guidance with structuring
projects.

I am wanting to develop a DLL assembly which will contain all my common
classes which will be used by various projects. During development of
this DLL assembly I have decided to have a second project which will be
a console application whose entire job is to run code to test the
classes to iron out bugs etc.

The seperate assembly is perfectly acceptable if the tests are acceptance
tests. Acceptance tests deal more with the public interface to your code and
are closer to what the user of the software is expecting. If theses tests
are unit tests then they should be within the assembly to avoid having to
expose your internal methods as public methods (so you can test them from
another assembly). Note that there is a thing called friend assemblies that
allow one assembly to see another assembly's internal methods but I have
never done this.

I have structured this in the following way:


A. I have a solution called XYZCommon (where XYZ is the Company Name).

B. This solution has two projects. Project 1 is called XYZCommon and
will create the DLL assembly. Project 2 is called XYZCommonTest which
is a console application. This will contain the code to test the
classes in XYZCommon.

C. Project XYZCommonTest is set as the Startup Project for the
solution. It also references project XYZCommon.

D. Project XYZCommonTest has multiple 'static void Main(string[] args)'
entry points in different classes. Each entry point will run a test for
the corresponding class in XYZCommon.

E. Before I run each test I set the required entry point as the Startup
Object property in project XYZCommonTest's project property page.

I would think that eventually you will want to run all the tests as a batch
so I would keep to one Main method and from that method start your tests. If
you are wanting to work on one test or one set of tests (all tests within a
test fixture) then you could use a command line argument. That is what NUnit
does.

This set up is allowing me to edit and test each class as I go within a
single solution. Is this a sensible way to develop and test a DLL
assembly? What do other people do?

It should not be test and move on never to run that test again. At least
once a day all tests should be run and all tests should be run before
checking in your code (you are using something like SourceSafe, right?)

PS

 

[Guest]

Sounds about how we test our BL dlls however I don't really see the need to
have multiple entry point within your XYZCommonTest project. You can set up
the calls with the same class to test the various classes in XYZCommon.dll
but pass in an arg to your test app, which will be used to determine which
class you would like to test.

Example to test you to test the valdation class in you dll pass an arg =
"Validate"
Which your test app will then use to determine that it needs to test the
validate methods exposed on your XYZCommon's facade.

Hope this was helpful.

 

[Jon Skeet [C# MVP]]

I'm new to Visual C# and I am looking for guidance with structuring
projects.

I am wanting to develop a DLL assembly which will contain all my common
classes which will be used by various projects. During development of
this DLL assembly I have decided to have a second project which will be
a console application whose entire job is to run code to test the
classes to iron out bugs etc.

Any reason for using a console application rather than having unit
tests using a commonly available framework such as NUnit? Then the
tests could either live in another library project, or if you don't
mind them being shipped (or want to use conditional compilation to
exclude them) they could live in the same project as the production
code.

 

[JohnGoogle]

Thanks to you all!

I've downloaded the NUnit stuff (never heard of it before) and had a
quick look and it seems to be able to provide all the functionality I
require.

As it's early on in my development I will be able to convert my
validation / test code to be used by NUnit.

Thanks again!

John.

 

[PS]

Thanks to you all!

I've downloaded the NUnit stuff (never heard of it before) and had a
quick look and it seems to be able to provide all the functionality I
require.

As it's early on in my development I will be able to convert my
validation / test code to be used by NUnit.

Also check out TestDriven.net. This is a Visual Studio add in that allows
you to run a test from within VS and understands the NUnit test fixtures.

PS

 

[Angel Of Death]

Also check out TestDriven.net. This is a Visual Studio add in that
allows you to run a test from within VS and understands the NUnit test
fixtures.

PS

Can you use an App.config with TestDriven, like you can with NUnit?

 

[PS]

Can you use an App.config with TestDriven, like you can with NUnit?

Yes, it will use the MyDll.dll.config file in the output path directory.

PS