I'd look into using a run-time text template. I used this with great success on a project to make my email sending logic testable.

I created a template called MyEmailTemplate (example name). In order to test the actual functionality of the template generation, I wrote unit tests for the class directly. I was able to accomplish this by keeping the methods stateless and free of side effects--just return a string based on the inputs. Once I got a layer up, I had to then figure out how to mock the template to test the layers dependent on email functionality.

The way I structured it, I had my DI container wire up an factory object I named IEmailTemplateFactory (I used Castle Windsor's TypedFactoryFacility, if you're interested) that then had a factory method that generated an instance of an IMyEmailTemplate. I would inject that factory instead of directly injecting the message into every object that needed to deal with emails. I used the factory to overcome the problem posed from the fact that when using DI you generally only have the container manage one instance of a dependency for the whole app lifetime--you don't want to be dealing with a persistent MailMessage instance. IMyEmailTemplate was an interface I defined to make it testable--it only defines the TransformText() method so I could mock the template output in my tests. I then applied the interface to the template by taking advantage of the fact that the template class that is generated for you is partial.

I had a lot of success with this method, and I think it will work great for you as well.

I'd look into using a run-time text template. I used this with great success on a project to make my email sending logic testable.

I created a template called MyEmailTemplate (example name). In order to test the actual functionality of the template generation, I wrote unit tests for the class directly. I was able to accomplish this by keeping the methods stateless and free of side effects--just return a string based on the inputs. Once I got a layer up, I had to then figure out how to mock the template to test the layers dependent on email functionality.

The way I structured it, I had my DI container wire up an factory object I named IEmailTemplateFactory (I used Castle Windsor's TypedFactoryFacility, if you're interested) that then had a factory method that generated an instance of an IMyEmailTemplate. I would inject that factory instead of directly injecting the message into every object that needed to deal with emails. I used the factory to overcome the problem posed from the fact that when using DI you generally only have the container manage one instance of a dependency for the whole app lifetime--you don't want to be dealing with a persistent MyEmailTemplate instance. IMyEmailTemplate was an interface I defined to make it testable--it only defines the TransformText() method so I could mock the template output in my tests. I then applied the interface to the template by taking advantage of the fact that the template class that is generated for you is partial.

I had a lot of success with this method, and I think it will work great for you as well.

Addendum: I should add that the rest of the mail functionality can and should be handled with the factory approach. Instead of injecting a MailAddress or MailMessage, which can quickly become problematic, use the factory approach. Additionally, depending on your DI framework, you might be able to directly inject values from your config file into your constructors (I know Windsor supports this).

I'd look into using a run-time text template. I used this with great success on a project to make my email sending logic testable.

I created a template called MyEmailTemplate (example name). In order to test the actual functionality of the template generation, I wrote unit tests for the class directly. I was able to accomplish this by keeping the methods stateless and free of side effects--just return a string based on the inputs. Once I got a layer up, I had to then figure out how to mock the template to test the layers dependent on email functionality.

The way I structured it, I had my DI container wire up an IEmailTemplateFactory (Castle Windsor's TypedFactoryFacility, if you're interested) that then had a factory method that generated an instance of an IMyEmailTemplate. I would inject that factory instead of directly injecting the message into every object that needed to deal with emails. I used the factory to overcome the problem posed from the fact that when using DI you generally only have the container manage one instance of a dependency for the whole app lifetime--you don't want to be dealing with a persistent MailMessage instance. IMyEmailTemplate was an interface I defined to make it testable--it only defines the TransformText() method so I could mock the template output in my tests. I then applied the interface to the template by taking advantage of the fact that the template class that is generated for you is partial.

I had a lot of success with this method, and I think it will work great for you as well.

I'd look into using a run-time text template. I used this with great success on a project to make my email sending logic testable.

I created a template called MyEmailTemplate (example name). In order to test the actual functionality of the template generation, I wrote unit tests for the class directly. I was able to accomplish this by keeping the methods stateless and free of side effects--just return a string based on the inputs. Once I got a layer up, I had to then figure out how to mock the template to test the layers dependent on email functionality.

The way I structured it, I had my DI container wire up an factory object I named IEmailTemplateFactory (I used Castle Windsor's TypedFactoryFacility, if you're interested) that then had a factory method that generated an instance of an IMyEmailTemplate. I would inject that factory instead of directly injecting the message into every object that needed to deal with emails. I used the factory to overcome the problem posed from the fact that when using DI you generally only have the container manage one instance of a dependency for the whole app lifetime--you don't want to be dealing with a persistent MailMessage instance. IMyEmailTemplate was an interface I defined to make it testable--it only defines the TransformText() method so I could mock the template output in my tests. I then applied the interface to the template by taking advantage of the fact that the template class that is generated for you is partial.

I had a lot of success with this method, and I think it will work great for you as well.