i in process of retrofitting unit tests asp.net solution written in vb.net , c#. unit tests need verify current functionality , act check future breaking changes.
the solution comprises of:
1 mvc web project written in vb.net (don't ask, it's legacy thing)
10 other supporting projects each containing logically grouped functionality written in c#, each project contains repositories , dal
all classes tightly coupled there no inversion of control (ioc) implemented anywhere, yet.
currently test controller there following stack:
- controller
- repository
- dal
- logging
first question, unit test correctly setup 1 test project , run tests it, or should setup 1 test project each project test functionality of dll only?
second question, need implement ioc able use moq?
third question, possible refactor ioc huge solution this?
forth question, other options available done asap?
i in process of retrofitting unit tests asp.net solution written in vb.net , c#. unit tests need verify current functionality , act check future breaking changes.
when working large code base doesn't have unit tests , hasn't been written testing in mind, there chance in order write useful set of unit tests have modify code, hence you're going triggering event you're planning on writing unit tests support. risky, may not riskier you're doing on day day basis.
there number of approaches take (and there's chance question closed broad). 1 approach create set of integration tests ensure core functionality working. these tests won't fast run unit tests, further decoupled legacy code base. give safety net changes need make part of introducing unit testing.
if have appropriate version of visual studio, may able use shims (or if have funds, typemock may option) isolate elements of application when writing initial tests. so, example create shims of dal isolate rest of code db.
first question, unit test correctly setup 1 test project , run tests it, or should setup 1 test project each project test functionality of dll only?
personally, prefer think of each assembly testable unit, tend create @ least 1 test project each assembly containing production code. whether or not makes sense though, depends bit on what's contained in each of assemblies... i'd tend have @ least 1 test project integration tests of top level project.
second question, need implement ioc able use moq?
the short answer no, depends classes do. if want test using moq, it's easier if classes support dependency injection, although don't need use ioc container achieve this. hand rolled injection either through constructors below, or through properties can form bridge allow testing stubs injected.
public someconstructor(isomedependency somedependency = null) { if(null == somedependency) { somedependency = new somedependency(); } _somedependency = somedependency; } third question, possible refactor ioc huge solution this?
yes it's possible. bigger question worth it? appear suggesting big bang approach migration. if have team of developers don't have experience in area, seems awfully risky. safer approach might target specific area of application , migrate section. if assemblies discrete should form easy split points in application. learn works , doesn't, along benefits , unexpected pain you're feeling. use inform decision how , when migrate rest of code.
forth question, other options available done asap?
as i've said above, i'm not sure asap right approach take. working towards unit-testing can done slow migration, adding tests change code due business requirements. helps ensure testers allocated catch errors introduce part of refactoring might need take place support testing.
Comments
Post a Comment