We just started to reorganize our code and are separating the DAL from the Business. We have also started playing with unit testing, but we've come up with a few problems.
1) Unit testing the DAL. Yes, we've noticed that this is not a trivial task, and are looking at using the com+ / service enterprise approch. The quuestion is: Are there any help for adding rollback option built into the Team Systems
2) Unit testing the Business. Quite a few of our business class depends quite heavily on the data access layer. The problem occurs when we create an instance of a business class, it requires a lot of DAL access. Typically today this access is built into the constructor, and it calls a lot of DAL components to get all entities required. We're unsure how to handle this. We have come up with three options:
- Adding #ifdefs in the code, wich allows for switching between mock objects and the DAL object
- Adding interfaces to the DAL objects (currently we dont have it. Should we always use interfaces on the DAL I don't see why except for unit testing) Adding interface would add possibility for a factory creation of the DAL objects, and thus allow for creating mock objects instead.
- Doing integration test instead. That is testing the business objects together with the DAL objects directly connected with the test database.
We're currently in a steep learning process both in unit testing and following the best practice, so please correct me if I've misunderstood anything.
Thanks for any guidance.
Larsi

Dependency between Business and DAL - Problems with unit testing
Alexander Mossin
Thanks for your answers.
I've tried out the nmock, and it works fine in some cases. But I've found that it complicates the code to allow for insertion of custom context in all (exsisting) code.
So far we have decided to go for a "integration" type of unittesting.
Larsi
_mubashir
The problems you are seeing with isolation are due to the dependency between them. An approach that will enable you better isolation is to depend on abstraction (Interfaces) instead (see for example http://www.objectmentor.com/resources/articles/dip.pdf). An added benefit is that you can then use Mock Objects (e.g. http://www.nmock.org/ http://sourceforge.net/projects/dotnetmock etc) to simulate the environment for the unit under test
Otherwise, as Greg pointed out, you'd be stuck with your 3rd option - increasing the "unit" size and doing integration tests
Arnon
Anna Ahn
Larsi,
Unfortunately you see alot of the 3rd option if you are fairly far down the path.
This may not help you much now but Jimmy Nilsson discusses this exact issue in http://www.amazon.com/exec/obidos/tg/detail/-/0321268202/qid=1143871972/sr=1-2/ref=sr_1_2/102-3319163-1611303 v=glance&s=books including some common methodologies to avoiding it.
http://msdn.microsoft.com/msdnmag/issues/05/06/UnitTesting/ may also be worth a read for you.
Cheers,
Greg