So I'm trying to write some test cases for my business logic layer. I've already mocked up my data access layer (which returns NHibernate IQueryOver objects). I created a MockQueryOver class that implements the IQueryOver interface because I chain functions in the business logic layer so creating a stubbed IQueryOver didn't make sense to me.
Anyway, that all works, but the problem I'm having is when I try to do an OrderBy() on the QueryOver. In my MockQueryOver class, I implement the OrderBy() method like this right now:
public IQueryOverOrderBuilder<TRoot, TSubType> OrderBy(Expression<Func<TSubType, object>> path)
{
var func = path.Compile();
IList<TSubType> result = m_data.OrderBy(func).ToList();
var mockRepo = new MockRepository();
var queryOver = new MockQueryOver<TRoot, TSubType>(m_data);
IQueryOverOrderBuilder<TRoot, TSubType> mockOrderBuilder = mockRepo.StrictMock<IQueryOverOrderBuilder<TRoot, TSubType>>(queryOver, path);
mockOrderBuilder.Stub(x => x.Desc).Return(queryOver);
mockOrderBuilder.Stub(x => x.Asc).Return(queryOver);
return mockOrderBuilder;
}
The problem is that RhinoMocks throws an exception on any of the Stub methods. This is the exception:
System.NullReferenceException : Object reference not set to an instance of an object.
at NHibernate.Criterion.Lambda.QueryOverOrderBuilderBase`3.AddOrder(Func`2 orderStringDelegate, Func`2 orderDelegate)
at NHibernate.Criterion.Lambda.QueryOverOrderBuilderBase`3.get_Desc()
at NHibernate.Criterion.QueryOverBuilderExtensions.Desc(IQueryOverOrderBuilder`2 builder)
at BLL.Tests.Mock_Objects.MockQueryOver`2.<OrderBy>b__7(IQueryOverOrderBuilder`2 x) in MockQueryOverSubType.cs: line 239
I'm new to NHibernate and RhinoMocks, so I'm not sure what it's doing behind the scenes, but it seems like even though I'm creating a mock of an interface, it still calls concrete extension methods when I try to stub a method.
Can someone please clarify this or help me out with this problem? Also, since I'm just beginning to write these test cases, I don't mind switching mocking frameworks, as long as it's free to use.
Thanks a lot!
Are you certain IQueryOverOrderBuilder is an interface? It seems to be a confusingly-named class that implements QueryOverOrderBuilderBase. I'm not entirely sure what the behaviour is in this situation, but I think your StrictMock of IQueryOverOrderBuilder is actually calling through to that base class, which probably isn't set up, and is throwing the exception you're seeing.
I think that perhaps you might need add another abstraction layer in between your business logic and NHibernate, with classes that you can reliably mock. I don't think there's a way of mocking a concrete class like IQueryOverOrderBuilder with RhinoMocks (but I'm happy to be corrected if there is :).
To create another abstraction layer, analyse the operations in your business logic that currently interact with NHibernate, and define a new interface of functions to encapsulate those operations (say, IRepository). Code that adds something to the database through NHibernate might become a function on the interface named AddItem. Move the code that interacts with NHibernate behind this interface into new functions on a new class (there's no reason why it needs to be a single class - you could group logically-related code into separate classes with separate interfaces). The new interface might be able to reference some NHibernate classes and interfaces that can be easily instantiated or mocked, respectively (ideally, the interface wouldn't reference NHibernate at all, but you're doing this for testing, not to fully decouple your code from NHibernate, so it's fine). Once you've done this, your business logic can be unit-tested against a mock (or mocks) of the new interface, and the class or classes that implement that interface can be integration tested against an actual database. This is, loosely, the Adapter pattern. Without seeing exactly what your business logic does, it's difficult to comment further on the design. I hope this is helpful.
Finally, if you're creating your own MockRepository, I think you need to call Replay() on the mocks you create (or ReplayAll() on the MockRepository) after you stub them. You don't need to do this if you create your mocks from the static methods on MockRepository. Seems unrelated to your current issue (although, try calling it after your Stub calls and see if it makes any difference), but I thought I'd mention it anyway.
Related
Overview
I am making a .net-core web API with simple CRUD operations.
I have made the GET methods and got them up and running, however when I try to implement the Create method using dbContext.Add(myItem) I am not able to use dbContext.SaveChanges() afterwards.
My current work is available at:
https://github.com/petermefrandsen/TKD-theory-API
So far
I have tried adding a overwriting method to my database context.
Additionally I have tried adding the entity framework reference to the project.
As I do use interfaces for loose coupling I am at a loss when I comes to comparing with tutorials and other peoples similar problems. (read I am fairly new to c#).
Code
Controller:
[Route("dan/")]
[HttpPost]
public ActionResult<DanTheoryItem> PostDanTheoryItem(DanTheoryItem danTheoryItem)
{
_context.PostDanTheoryItem(danTheoryItem);
return new ActionResult<DanTheoryItem>(danTheoryItem);
}
IContext:
DanTheoryItem PostDanTheoryItem(DanTheoryItem danTheoryItem);
Context:
public DanTheoryItem PostDanTheoryItem(DanTheoryItem danTheoryItem)
{
var theoryItem = new DbDanTheoryItems
{
Id = danTheoryItem.Id,
KoreanTheoryItemId = danTheoryItem.KoreanTheoryItemId,
MainCategory = danTheoryItem.MainCategory,
SubCategory = danTheoryItem.SubCategory,
SubToSubCategory = danTheoryItem.SubToSubCategory,
NameLatin = danTheoryItem.NameLatin,
NamePhonetic = danTheoryItem.NamePhonetic,
NameAudio = danTheoryItem.NameAudio
};
_dbContext.DanTheoryItems.Add(theoryItem);
//_dbContext.SaveChanges();
return danTheoryItem;
}
Desired result
I'd like to have the controller call the context methods that will write the desired data to the database.
Your interface doesn't contain a SaveChanges method. Since you are using dependency injection only the methods in your interface will be available to your controller.
If you inherit from System.Data.Entity.IDbContext class in your custom interface, the method will be exposed to you in your controller.
Instantiating an instance of your DbLokisaurTKDTheoryAppContext class in your controller will expose the SaveChanges method as well.
It's hard to say exactly because you've neglected to post certain key portions of your code. However, my best guess is that you "context" is being provided IDbContext (of your own creating), instead of DbContext, and your interface doesn't define a SaveChanges method.
Honestly, just get rid of IDbContext. The point of an interface is to define a contract between multiple implementations. Here, there can be only one implementation: DbContext, and DbContext isn't even aware of this interface. Just inject your derived DbContext directly.
Using an interface isn't a magic wand. You have a hard dependency on Entity Framework here, so interface or not, you're tightly coupled. That's not necessary a bad thing though. EF is serving as your data layer, and this application is data driven; it's going to be tightly coupled to the data layer no matter what.
The API itself serves as your abstraction. Other layers will presumably just use the API, so no further abstraction is necessary, and in fact just adds more maintenance concern with no added benefit.
Let's say I have a Castle.DynamicProxy object that is created by a third party. In this case Rhino.Mocks.
var rhinoObj = MockRepository.GenerateMock<IMyType>();
For one reason or another I want to be able to use this generated object by Rhino and add another interceptor to it so I can manipulate it without using Rhino itself.
I understand this may seem weird, its for a mocking library I'm writing myself that I want integrated with other mocking frameworks that use Castle, such as Rhino.
I have tried:
generator.CreateInterfaceProxyWithTarget(rhinoObj, new MyInterceptor())
But Rhino complains when I wish to use anything such as .Stub(..) that this is not a mocked object - so clearly the rhino interceptors are overwritten.
I know it is an old question but I had the same problem. Reading my own answer 2 days ago would have saved me several hours...
The Problem
Rhino.Mocks with the help of castle dynamic proxy generates a new type based on your interface, creates an instance of it and returns it to you. This instance is also used as a rhino.mock-internal key to look up all mocking-things (assertions, return values, ...).
Now you create a proxy (means: another new type and another new instance) around the rhino.mock-object and the lookup-by-instance does not work anymore. You need the original object somehow.
Option 1
You need to keep the original object from rhino.mocks around. How this will look depends on your overall setup. Maybe all instances creation goes through a central repository and you can add handy accessor methods like those:
internal interface IMockRepository
{
void Add(object key, object mock);
T GetMock<T>(T key);
object GetMock(object key);
}
This should the trick any mocking framework, not just rhino.mocks. On the minus-side is extra infrastructure and boilerplate code. And the akward feeling that you create a proxy around a proxy.
Option 2
(based on this answer): Rhino.mocks also uses castle dynamic proxies and interceptors. Maybe we can sneak in our own interceptor? We can!
var mock = Rhino.Mocks.MockRepository.GenerateStub(type);
dynamic dyn = mock;
dyn.__interceptors = new[] {new MyInterceptor(), dyn.__interceptors[0]};
You need to use IInterceptor and IInvocation from Castle.Core.Interceptor instead of Castle.DynamicProxy but the interfaces are identical. The original proxy must come last.
This relies on rhino.mocks-internals which might change in any future release without notice. But I think it is save to assume that (a) rhino.mocks will continue to use castle dynamic proxies and (b) dynamic proxies will be dynamics also in future. So if something breaks, it should be fixable.
This is more "hacky" but I use this solution. No "proxy-of-proxy"-thing and no boilerplate.
I am working with .net c# Mvc, using ninject repository pattern. My problem is that when developing I am using reusing in the functions, and everytime I want more info from db and need access to another table, I need to pass the repositories from all the places that are calling this function. Am I doing it wrong? ot this is the way, which is alot longer to develop then just opening a connection and disposing at the end of the function.
If your class needs to have loads of repositories passed in this can sometimes be a sign that your class is doing too many things and probably breaking the Single Responsibility Principle.
Perhaps if you broke this class into smaller more specialized classes the problem would not be so bad.
On the other hand, sometimes passing in loads of repositories is unavoidable. You might consider making a factory class that creates the class suffering from 'constructor jam' for you - this should save some typing as the hefty constructor initialization is just in one place (in the factory class).
edit: A really simple 'factory' class might be as follows:
public class FactoryClass
{
public ClassWithLotsOfRepositories GetClassWithLotsOfRepositories()
{
return new ClassWithLotsOfRepositories(new repository1(),
new repository2(), new repository3() );
}
}
So you can now create an instance of ClassWithLotsOfRepositories without having to specify the repositories in the constructor each time.
ClassWithLotsOfRepositories myClassThatUsesLotsOfRepositories = new FactoryClass().GetClassWithLotsOfRepositories();
My example has concrete classes passed in through the constructor. You are using Ninject so presumably have interfaces that need resolving - I'm just keeping this example simple to illustrate the concept.
use a unit of work the new up all of the repositories. That way you can pass in the uow into your controllers and have access to all repos when needed.
Currently we have implemented a repository pattern at work. All our repositories sit behind their own interfaces and are mapped via Ninject. Our project is quite large and there are a couple quirks with this pattern I'm trying to solve.
First, there are some controllers where we need upwards of 10 to 15 repositories all in the same controller. The constructor gets rather ugly when asking for so many repositories. The second quirk reveals itself after you call methods on multiple repositories. After doing work with multiple repositories we need to call the SaveChanges method, but which repository should we call it on? Every repository has one. All repositories have the same instance of the Entity Framework data context injected so picking any random repository to call save on will work. It just seems so messy.
I looked up the "Unit Of Work" pattern and came up with a solution that I think solves both problems, but I'm not 100% confident in this solution. I created a class called DataBucket.
// Slimmed down for readability
public class DataBucket
{
private DataContext _dataContext;
public IReportsRepository ReportRepository { get; set; }
public IEmployeeRepository EmployeeRepository { get; set; }
public IDashboardRepository DashboardRepository { get; set; }
public DataBucket(DataContext dataContext,
IReportsRepository reportsRepository,
IEmployeeRepository employeeRepository,
IDashboardRepository dashboardRepository)
{
_dataContext = dataContext;
this.ReportRepository = reportsRepository;
this.EmployeeRepository = employeeRepository;
this.DashboardRepository = dashboardRepository;
}
public void SaveChanges()
{
_dataContext.SaveChanges();
}
}
This appears to solve both issues. There is now only one SaveChanges method on the data bucket itself and you only inject one object, the data bucket. You then access all the repositories as properties. The data bucket would be a little messy looking since it would be accepting ALL (easily 50 or more) of our repositories in its constructor.
The process of adding a new repository would now include: creating the interface, creating the repository, mapping the interface and repository in Ninject, and adding a property to the data bucket and populating it.
I did think of an alternative to this that would eliminate a step from above.
public class DataBucket
{
private DataContext _dataContext;
public IReportsRepository ReportRepository { get; set; }
public IEmployeeRepository EmployeeRepository { get; set; }
public IDashboardRepository DashboardRepository { get; set; }
public DataBucket(DataContext dataContext)
{
_dataContext = dataContext;
this.ReportRepository = new ReportsRepository(dataContext);
this.EmployeeRepository = new EmployeeRepository(dataContext);
this.DashboardRepository = new DashboardRepository(dataContext);
}
public void SaveChanges()
{
_dataContext.SaveChanges();
}
}
This one pretty much eliminates all the repository mappings in Ninject because they are all instantiated in the data bucket. So now the steps to adding a new repository include: Create interface, create repository, add property to data bucket and instantiate.
Can you see any flaws with this model? On the surface it seems much more convenient to consume our repositories in this way. Is this a problem that has been addressed before? If so, what is the most common and/or most efficient approach to this issue?
First, there are some controllers where we need upwards of 10 to 15 repositories all in the same controller.
Say hello to Abstract factory pattern. Instead of registering all repositories in Ninject and injecting them to controllers register just single implementation of the factory which will be able to provide any repository you need - you can even create them lazily only if the controller really needs them. Than inject the factory to controller.
Yes it also has some disadvantages - you are giving controller permission to get any repository. Is it problem for you? You can always create multiple factories for some sub systems if you need or simply expose multiple factory interfaces on single implementation. It still doesn't cover all cases but it is better than passing 15 parameters to constructor. Btw. are you sure those controllers should not be split?
Note: This is not Service provider anti-pattern.
After doing work with multiple repositories we need to call the SaveChanges method, but which repository should we call it on?
Say hello to Unit of Work pattern. Unit of Work is logical transaction in your application. It persists all changes from logical transaction together. Repository should not be responsible for persisting changes - the unit of work should be. Somebody mentioned that DbContext is implementation of Repository pattern. It is not. It is implementation of Unit of Work pattern and DbSet is implementation of Repository pattern.
What you need is central class holding the instance of the context. The context will be also passed to repositories because they need it to retrieve data but only the central class (unit of work) will offer saving changes. It can also handle database transaction if you for example need to change isolation level.
Where should be unit of work handled? That depends where your logical operation is orchestrated. If the operation is orchestrated directly in controller's actions you need to have unit of work in the action as well and call SaveChanges once all modifications are done.
If you don't care about separation of concerns too much you can even combine unit of work and factory into single class. That brings us to your DataBucket.
I think you are absolutely right to use the Unit of Work pattern in this case. Not only does this prevent you from needing a SaveChanges method on every repository, it provides you a nice way to handle transactions from within code rather than in your database itself. I included a Rollback method with my UOW so that if there was an exception I could undo any of the changes the operation had already made on my DataContext.
One thing you could do to prevent weird dependency issues would be to group related repositories on their own Unit of Work, rather than having one big DataBucket that holds every Repository you have (if that was your intent). Each UOW would only need to be accessible at the same level as the repositories it contained, and other repositories should probably not depend on other UOWs themselves (your repositories shouldn't need to use other repositories).
If wanted to be an even bigger purist of the pattern, you could also structure your UOWs to represent just that, a single Unit of Work. You define them to represent a specific operation in your domain, and provide it with the repositories required to complete that operation. Individual repositories could exist on more than one UOW, if it made sense to be used by more than one operation in your domain.
For example, a PlaceCustomerOrderUnitOfWork may need a CustomerRepository, OrderRepository, BillingRepository, and a ShippingRepository
An CreateCustomerUnitOfWork may need just a CustomerRepository. Either way, you can easily pass that dependency around to its consumers, more fine grained interfaces for your UOW can help target your testing and reduce the effort to create a mock.
The notion of every repository having a SaveChanges is flawed because calling it saves everything. It is not possible to modify part of a DataContext, you always save everything. So a central DataContext holder class is a good idea.
Alternatively, you could have a repository with generic methods that can operate on any entity type (GetTable<T>, Query<T>, ...). That would get rid of all those classes and merge them into one (basically, only DataBucket remains).
It might even be the case that you don't need repositories at all: You can inject the DataContext itself! The DataContext by itself is a repository and a full fledged data access layer. It doesn't lend itself to mocking though.
If you can do this depends on what you need the "repository" do provide.
The only issue with having that DataBucket class would be that this class needs to know about all entities and all repositories. So it sits very high in the software stack (at the top). At the same time it is being used by basically everything so it sits at the bottom, too. Wait! That is a dependency cycle over the whole codebase.
This means that everything using it and everything being used by it must sit in the same assembly.
What I have done in the past was to create child injection containers (I was using Unity) and register a data context with a ContainerControlledLifetime. So that when the repositories are instantiated, they always have the same data context injected into them. I then hang on to that data context and when my "Unit of Work" is complete, I call DataContext.SaveChanges() flushing all the changes out to the database.
This has some other advantages such as (with EF) some local caching, such that if more than one repository needs to get the same entity, only the first repository actually causes a database round trip.
It's also a nice way to "batch up" the changes and make sure they execute as a single atomic transaction.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
How to approach unit testing of private methods?
I have a class that loads Employee data into a database. Here is a sample:
>
public class EmployeeFacade
{
public Employees EmployeeRepository = new Employees();
public TaxDatas TaxRepository = new TaxDatas();
public Accounts AccountRepository = new Accounts();
//and so on for about 20 more repositories etc.
public bool LoadAllEmployeeData(Employee employee)
{
if (employee == null)
throw new Exception("...");
bool exists = EmployeeRepository.FetchExisting(emps.Id);
if (!exists)
{
EmployeeRepository.AddNew();
}
try
{
EmployeeRepository.Id = employee.Id;
EmployeeRepository.Name = employee.EmployeeDetails.PersonalDetails.Active.Names.FirstName;
EmployeeRepository.SomeOtherAttribute;
}
catch() {}
try
{
emps.Save();
}
catch(){}
try
{
LoadorUpdateTaxData(employee.TaxData);
}
catch() {}
try
{
LoadorUpdateAccountData(employee.AccountData);
}
catch() {}
... etc. for about 20 more other employee objects
}
private bool LoadorUpdateTaxData(employeeId, TaxData taxData)
{
if (taxData == null)
throw new Exception("...");
...same format as above but using AccountRepository
}
private bool LoadorUpdateAccountData(employee.TaxData)
{
...same format as above but using TaxRepository
}
}
I am writing an application to take serialised objects(e.g. Employee above) and load the data to the database.
I have a few design question that I would like opinions on:
A - I am calling this class "EmployeeFacade" because I am (attempting?) to use the facade pattern. Is it good practace to name the pattern on the class name?
B - Is it good to call the concrete entities of my DAL layer classes "Repositories" e.g. "EmployeeRepository" ?
C - Is using the repositories in this way sensible or should I create a method on the repository itself to take, say, the Employee and then load the data from there e.g. EmployeeRepository.LoadAllEmployeeData(Employee employee)? I am aim for cohesive class and but this will requrie the repository to have knowledge of the Employee object which may not be good?
D - Is there any nice way around of not having to check if an object is null at the begining of each method?
E - I have a EmployeeRepository, TaxRepository, AccountRepository declared as public for unit testing purpose. These are really private enities but I need to be able to substitute these with stubs so that the won't write to my database(I overload the save() method to do nothing). Is there anyway around this or do I have to expose them?
F - How can I test the private methods - or is this done (something tells me it's not)?
G- "emps.Name = employee.EmployeeDetails.PersonalDetails.Active.Names.FirstName;" this breaks the Law of Demeter but how do I adjust my objects to abide by the law?
A - I wouldn't call it XXXFacade, but something more meaningful (which may in fact mean you should call it XXXFacade)
B - I would call them XXXRepository
C - I don't really understand your model here - you're passing in an Employee object and assigning its values to the equivilent values in EmployeeRepository. The Repository shouldn't contain data fields - each instance of the repository does not represent a row in the database. The Repository is a way of getting data in and out of the database, by operating on collections of entities from the database (ie: Repository is the table, Entities are the rows). I would expect the Repository object to have a Save method which takes an Employee object as a parameter and it persists it to the database. As well as a Load method which takes an Id and returns and Employee:
Employee myEmployee = repository.Load(112345);
myEmployee.Name = "New Name";
repository.Save(myEmployee);
The Repository base class doesn't need to know about the specific implementation of the Employee class, through the use of generics and polymorphism. Take a look at Sh#rpArchitecture for a good example of this pattern.
D - yes, put that common logic in an abstract base class (Repository)
E - don't make them public if they should be private. If you need the use the logic of the repository in your unit tests to simulate fetching data, implement a common interface and then mock that interface out in your tests. You don't need to test that the repository returns the correct data since data is transient and inconsistent in reality. Better to fake it and test your behaviour does what you expect on precanned data from a mock repository.
F - Don't. Test behaviour not implementation.
G - I don't think this issue exists if you examine your architecture as described above.
How to approach unit testing of private methods?
You shouldn't write tests for private methods.
The only possible way of creating private methods is a refactorings of already tested public methods.
A - I am calling this class
"EmployeeFacade" because I am
(attempting?) to use the facade
pattern. Is it good practace to name
the pattern on the class name?
I don't think testing private methods a good idea; however, you can test "internal" classes, which are similar to private in the sense that external assemblies will not have access to them, by marking them as Internal Visible to your unit test project.
AssemblyInfo.cs --
[assembly: InternalsVisibleTo("YourClass.Tests")]
B - Is it good to call the concrete
entities of my DAL layer classes
"Repositories" e.g.
"EmployeeRepository" ?
I do this frequently, I don't think there is anything wrong with it.
C - Is using the repositories in this
way sensible or should I create a
method on the repository itself to
take, say, the Employee and then load
the data from there e.g.
EmployeeRepository.LoadAllEmployeeData(Employee
employee)? I am aim for cohesive class
and but this will requrie the
repository to have knowledge of the
Employee object which may not be good?
Unless I don't understand correctly, I would keep them seperate. I typically use my Repository classes as simply CRUD helpers, I would write a wrapper around the repository that exposes the functionality you need.
D - Is there any nice way around of
not having to check if an object is
null at the begining of each method?
If there is, I don't know it, I would just use ArgumentNullException()
E - I have a EmployeeRepository,
TaxRepository, AccountRepository
declared as public for unit testing
purpose. These are really private
enities but I need to be able to
substitute these with stubs so that
the won't write to my database(I
overload the save() method to do
nothing). Is there anyway around this
or do I have to expose them?
See my answer for A, marking them as Internal and then setting InternalsVisible To your unit test assembly. See also MSDN.
F - How can I test the private methods
- or is this done (something tells me it's not)?
I do not typically test private methods, and private classes that need to tested I mark as internal and use them in my test assembly.
A - I don't think its particularly bad to use the pattern name in the class name, though I honestly don't know how often it's done.
F - I think zerkms is right, you probably have to make them public, test them, then make them private when you're satisfied. Once their private, you could still test public methods that make use of the private methods to ensure they continue working.
As for your DAL and such, I would suggest looking into LINQ to SQL, available in .NET 3.0 and higher. It's a nice framework for handling the abstraction layer between your business logic and the database. Here are a few links to check out...
Quick Tutorial for LINQ to SQL in C#
Part 1 of Scott Guthrie's blog
Scott Guthrie has a lot of good stuff on LINQ, if you're interested, you should check out more of his posts.
A - IMO, yes. It immediate remind you the pattern, and help you understand the code, and this is maybe one of the important practices in code writing - letting other people understand your code.
B - I prefer the xxDAO convention (Data Access Object).
C - I prefer "service oriented programming", meaning a service that "knows" to save an employee and not a "repository object" that mix between "model" and "control".
D - Maybe using Aspect, but I don't recommend it.
E - You can create an interface for those classed, and inject them from "outside" using setters (just like spring does), or get them from some kind of factory, In that way it will be easy for you to replace the classes with mock, and still leave the members "private".
F - I think that those methods should be extracted out side of the "load employee" and be self services. IMO, you should abstract the "employee data" objects (especially if you got 20 of them :-)). and write a simple service that know to load a "employee data object" of any kind.
Hope that I helped,
Shay
Your naming convention seems ok.
By calling concrete repositories you are tightly coupling the system. Pass them repo objects in constructor. Or use a DI/IOC container.
If repository is returning employee it will know of it. You might want the repo to know the contract for an employee class.
If you are getting null value for something, you should make sure provider code does not send down nulls.
You can achieve that by implementing dependency injection properly and using interfaces.
Standard unit testing frameworks will not give you that, you will need something like Moles. A sample is show on this post
Use inheritance more than composition if you can. But if the object model requires that, then you are helpless in my opinion.