c# - Does composition root needs unit testing? -

i trying find answer seems it's not directly discussed lot. have composition root of application create di-container , register there , resolve needed top-level classes gets dependencies. happening internally - becomes hard unit test composition root. can virtual methods, protected fields , on, not big fan of introducing such things able unit test. there no big problems other classes use constructor injection. question - make sense test composition root @ all? have additional logic, not , in cases failures there pop during application start. code have:

public void initialize(/*some configuration parameters here*/)     {         m_container = new unitycontainer();          /*regestering dependencies*/          m_distributor = m_container.resolve<isimplefeedmessagedistributor>();     }      public void start()     {         if (m_distributor == null)         {             throw new applicationexception("initialize should called before start");         }          m_distributor.start();     }      public void close()     {         if (m_distributor != null)         {             m_distributor.close();         }     } 

does make sense test composition root @ all?

would know whether application written correctly? , that's why write tests. same reason should test composition root.

these tests targeted @ correctness of wiring of system. don't want test whether single class functions correctly, since that's covered unit test. neither want test whether classes call other classes in right order, because that's want test in normal integration tests (call mvc controller , see whether call ends in database example of such integration test).

here things should test:

• that top-level classes can resolved. prevents having click through screens in application find out whether wired correctly.
• that components depend on equally or longer lived services. when components depend on component configured shorter lifetime, component 'promote' lifetime of dependency, lead bugs hard reproduce , fix. checking kind of issues important. type of error known lifestyle mismatch or captive dependency.
• that decorators , other interception mechanisms crucial correctness of application applied correctly. decorators instance add cross cutting concerns such transaction handling, security , caching , important these concerns executed in right order (for instance security check must performed before querying cache), can hard test using normal integration test.

to able however, need have verifiable di configuration.

do note not everybody shares opinion though. experience verifying correctness of configuration highly valuable.

so testing these things can challenging ioc containers, while other ioc container have facilities (but unity unfortunately lacks of features).

some containers have sort of verification method can called verify configuration. 'verify' means differs each library. simple injector instance (i'm lead dev simple injector) has verify method iterate registrations , call getinstance on each of them ensure every instance can created. advice users call verify in composition root whenever possible. not possible instance because when configuration gets big, call verify can cause application start slowly. still, it's starting point , can remove lot of pain. if takes long, can move call automated test.

and simple injector, beginning. simple injector contains diagnostic services checks container on common misconfigurations, such earlier stated 'lifestyle mismatch'.

so should absolutely want test, i'm not sure whether call tests "unit tests", although manage run tests in isolation (without having hit database or web service).