shows the code that implements figure 4.5. in Visual C#

Generating QR Code ISO/IEC18004 in Visual C# shows the code that implements figure 4.5.

Figure 4.5 The web service will be stubbed out to simulate an exception; then the email sender will be mocked to see if it was called correctly. The whole test will be about how LogAnalyzer interacts with other objects.

public class LogAnalyzer2 { private IWebService service; private IEmailService email; public IWebService Service { get { return service; } set { service = value; } } public IEmailService Email { get { return email; } set { email = value; } } public void Analyze(string fileName) { if(fileName.Length<8) { try { service.LogError("Filename too short:" + fileName); } catch (Exception e) { email.SendEmail("a","subject",e.Message); } } } } [TestFixture] public class LogAnalyzer2Tests { [Test] public void Analyze_WebServiceThrows_SendsEmail() { StubService stubService = new StubService();

new Exception("fake exception");

MockEmailService mockEmail = new MockEmailService(); LogAnalyzer2 log = new LogAnalyzer2(); //we use setters instead of //constructor parameters for easier coding log.Service = stubService log.Email=mockEmail; Using properties instead of constructor injection string tooShortFileName="abc.ext"; log.Analyze(tooShortFileName); Assert.AreEqual("a",mockEmail.To); Assert.AreEqual("fake exception",mockEmail.Body); Assert.AreEqual("subject",mockEmail.Subject); } } public class StubService:IWebService { public Exception ToThrow; public void LogError(string message) { if(ToThrow!=null) { throw ToThrow; } } } public class MockEmailService:IEmailService { public string To; public string Subject; public string Body; public void SendEmail(string to, string subject, string body) { To = to;

Subject = subject; Body = body; } }

Note that the public properties we ve added will be used instead of a constructor. We ll use these setters to set the stub and mock, which will make the code easier to read and maintain. This code raises some interesting questions: Why are we doing several asserts in a single test How easy would it be to separate this test into three different tests with one assert each Could the three asserts be combined into a single logical test It can be quite tedious to create manual mocks and stubs for each test or test class. How can we overcome that Couldn t we have used the MockService from listing 4.1 as a stub We ll explore answers to these questions in the rest of this and the next chapter.

In a test where you test only one thing (which is how I recommend you write tests), there should be no more than one mock object. All other fake objects will act as stubs. Having more than one mock per test usually means you re testing more than one thing, and this can lead to complicated or brittle tests. (Look for more on this in chapter 7.) If you follow this guideline, when you get to more complicated tests, you can always ask yourself, Which one is my mock object Once you ve identified it, you can leave the others as stubs and not worry about assertions against them. Next, we ll deal with a more complex scenario: using a stub to return a stub or a mock that will be used by the application.

One of the most common scamming techniques online these days follows a simple path. A fake email is sent to a massive number of recipients. The fake email is from a fake bank or online service claiming that the potential customer needs to have a balance checked or to change some account details on the online site. All the links in the email point to a fake site. It looks exactly like the real thing, but its only purpose is to collect data from innocent customers of that business. This simple chain of lies is known as a phishing attack, and is more lucrative that you d imagine. Most people respond instinctively to these emails and do what s asked. Consequently, it s one of the biggest threats to identity theft in the world. How does this chain of lies matter to us Sometimes we want to have a fake component return another fake component, producing our own little chain of stubs in our tests, so that we can end up collecting some data during our test. A stub leads to a mock object that records data. The design of many systems under test allows for complex object chains to be created. It s not uncommon to find code like this:

IServiceFactory factory = GetServiceFactory(); IService service = factory.GetService();

Or like this:

String connstring = GlobalUtil.Configuration.DBConfiguration.ConnectionString;

Suppose you wanted to replace the connection string with one of your own during a test. You could set up the Configuration property of the GlobalUtil object to be a stub object. Then, you could set the DBConfiguration property on that object to be another stub object, and so on. It s a powerful technique, but you need to ask yourself whether it might not be better to refactor your code to do something like this: