C# Design Questions -

how approach unit testing of private methods?

i have class loads employee data database. here sample:

>

public class employeefacade    {     public employees employeerepository = new employees();       public taxdatas taxrepository = new taxdatas();       public accounts accountrepository = new accounts();       //and on 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. 20 more other employee objects      }        private bool loadorupdatetaxdata(employeeid, taxdata taxdata)     {         if (taxdata == null)            throw new exception("...");          ...same format above using accountrepository       }      private bool loadorupdateaccountdata(employee.taxdata)     {            ...same format above using taxrepository      } } 

i writing application take serialised objects(e.g. employee above) , load data database.

i have few design question opinions on:

a - calling class "employeefacade" because (attempting?) use facade pattern. practace name pattern on class name?

b - call concrete entities of dal layer classes "repositories" e.g. "employeerepository" ?

c - using repositories in way sensible or should create method on repository take, say, employee , load data there e.g. employeerepository.loadallemployeedata(employee employee)? aim cohesive class , requrie repository have knowledge of employee object may not good?

d - there nice way around of not having check if object null @ begining of each method?

e - have employeerepository, taxrepository, accountrepository declared public unit testing purpose. these private enities need able substitute these stubs won't write database(i overload save() method nothing). there anyway around or have expose them?

f - how can test private methods - or done (something tells me it's not)?

g- "emps.name = employee.employeedetails.personaldetails.active.names.firstname;" breaks law of demeter how adjust objects abide law?

a - wouldn't call xxxfacade, more meaningful (which may in fact mean should call xxxfacade)

b - call them xxxrepository

c - don't understand model here - you're passing in employee object , assigning values equivilent values in employeerepository. repository shouldn't contain data fields - each instance of repository not represent row in database. repository way of getting data in , out of database, operating on collections of entities database (ie: repository table, entities rows). expect repository object have save method takes employee object parameter , persists database. load method takes id , returns , employee:

employee myemployee = repository.load(112345); myemployee.name = "new name"; repository.save(myemployee); 

the repository base class doesn't need know specific implementation of employee class, through use of generics , polymorphism. take @ sh#rparchitecture example of pattern.

d - yes, put common logic in abstract base class (repository)

e - don't make them public if should private. if need use logic of repository in unit tests simulate fetching data, implement common interface , mock interface out in tests. don't need test repository returns correct data since data transient , inconsistent in reality. better fake , test behaviour expect on precanned data mock repository.

f - don't. test behaviour not implementation.

g - don't think issue exists if examine architecture described above.