How to unit test an email client

Question

I'm working on a desktop email client right now, and I want to unit test my backend. However, I can't see a way to make that work. In order for my code to work, it has to connect to a working mail server. Unless I tie my unit tests to an email account, and make sure that account matches the state my tests expect, I don't see how I can manage this.

Does anyone have any ideas on how to test this sort of application, where it relies on external factors by design?

EDIT:

To add some details: I'm working on a C++ higher level mail client library for my application, which uses libEtPan, a C library, to actually handle the details of connecting to the mail server and interacting with it.

Answer 1

I would mock the email server, and configure that mocked object to accept/reject emails as appropriate (depending on your tests).

To do this effectively, you need an interface to talk to your email server through. For testing, the implementation is a mocked object. For deployment you substitute this with an implementation that talks directly to a mail server.

See this SO question for C++ mocking frameworks.

Answer 2

As you most likely don't want to test you use of sockets, you might think about replacing that part of your code with a dummy server implementation that doesn't involve any TCP communication. Just hardcode the expected requests from your client and let your dummy server respond appropriately.

Answer 3

You just have to find a way to replace the real thing with a stub, that is fully under your control. Usually, this is done with mocking frameworks like Rhino.Mocks.

Btw.: If you'd use a 'real' email account, then it's not a unit test anymore, but an integration test...

Answer 4

I'm going to assume by testing the back end you are referring to the bit of code that actually talks to the Email server and to test the rest of your software you have mocked this layer.

Now this may or may not be integration tests depending on your definition unit. Frankly I don't care what you decide to call it but if you write some automated tests that are quick to run and are executed often then they might as well use the same platform as your unit tests.

I'd try to write this so it can work in at lest the following two ways - The first would be that it connects to an process-local email server that you can set up and configure as you need. In Java I use Dumpster but I'm sure alikes exist for C++. The second would be to connect to at least one local email server that you can script. One that you can splatter as much as you like (so NOT real or shared between developers¹) and run the same set of tests against that. The reason being that the developers of SMTP servers hate everyone and you will want to check that your stub works the same as a real thing. This I see as the equivalent to One Database Per Developer.

Now if you have not written your own SMTP client and just have a facade around an existing 3rd party API I less likely to "integration test" this on the assumption that the 3rd party API has been battered enough that bugs have already fallen out. I would look at mocking the 3rd party API and validating that the facade works as expected.

1) Maybe you could do this just during the CI cycle, so then share one set of email servers between all developers and the local run just uses a C++ Dumpster alike.

Answer 5

Andrew is correct about Mocking the mail API. Your problem with this being in C can be addressed in one of two ways.

• provide a simple C++ wrapper that can be mocked.
• Use the linker to provide your test/mock version of the C api, you must use the same header files as the library provides but your unit tests link with your mock C functions instead of the library.

There is a great book that addresses how to unit test in difficult situations: "Working Effectively with Legacy Code", I cannot recommend this book highly enough. Don't be put off by the title, the book regards legacy code as any code without unit tests.