First off, when I say legacy, I mean code I've written myself, code I've written in the last 18 months that I'm just not proud of, code that is now problematic to maintain and will probably put me in the nominations for lifehacker.com shame of productivity gallery (if such exist).

The code revolves around a CRM with callout to a quoting system. It is has a frontend that communicates to a WCF service endpoint (a fancy ASMX for those new to WCF). With each new feature and fix and trying to refactor to make it more maintainable and testable.

A couple of questions more TDD related but hopefully relevant to this forum as it revolves around LLBLGen for entities and DAL, e.g. I receive a request today to automatically save a quote against a customer as an attachment anytime a quote is ran. So TDD style, in UltimateCRM.Server.Tests I create add a method call SaveQuoteAgainstCustomer(customerId, storedQuoteId) and then realise that I dont have all the functionality in my lower level classes to accomplish this.. Now this is where I'm debating.. Do I create another Test to stub out the functionality at a lower level, which in turn might need me to create an even lower level Test and again satisfy this... Or do I keep whatever it takes in the simplest form to get top level test SaveQuoteAgainstCustomer working even if it means that some of the lower level functionality is blacked boxed.

Ultimately it would be be difficult to get high code/test coverage on code behind the service layer on the higher level tests, but I'm expected to use these tests to define my code. I guess I need to get high test coverage without the bottom-up approach as there's too much risk for over-engineering and wasted code/time/thinking.

What are you're thoughts?

Second how do you suggest handling transient domain objects neatly (i.e. those central to your app that have no ties to your DB, e.g. might be called in from a WS, calculate or statistical) when using the LLBLGen entities as your domain objects e.g. llblgen adapter 2 class - UltimateCRM.Domain.

Would I be going OTT by abstracting PersonEntity to IPerson for use in the BBL PersonManager (essentially another layer under PersonService that makes call to the DAL e.g. GetPersonByLoyaltyCard(string))

Ideas? Approaches?