Sounds like it might be more beneficial for you to look into unit testing (and/or TDD) before jumping into Rhino Mocks. Rhino Mocks (and other mocking frameworks) are used to generate mock implementations a class' dependencies, but I found the best way to learn was to code these mocks by hand until it became annoying enough to switch to a framework.
> ... > First I am unsure why you have this > > public class InvoiceSender and not this. > > public class InvoiceSender : IEmailService > The InvoiceSender uses the IEmailService. This is called dependency injection (more shameless blog plugs: http://www.davesquared.net/2008/06/attempting-to-understand-dependency.html). By isolating different parts of functionality we can unit test our code easier. > You have this > > private readonly IEmailService emailService; > public InvoiceSender(IEmailService emailService) > { > this.emailService = emailService; > } > > > I am not sure ...why you are setting this all up in the > constructor(or even why you have the constructor) and where exactly > the code is that will pass in the parameter for the constructor. This is called constructor injection -- it refers to injecting a class' dependencies in via the constructor (as opposed to setter injection). The IEmailService implementation is instantiated by whichever code instantiates the InvoiceSender class. > In the SendInvoice I don't understand why your actually using > MailMessage like your not really sending the message or anything(hence > mocking?). So why could you just got something else there instead(I > dont' a random string or stuff). Since if I understand it right its > not like the what every you have will be returned since Send() is > Void. > The idea is we have isolated our InvoiceSender code -- it needs to generate a new MailMessage, and use the IEmailService to send it. If we did not have an IEmailService interface, we'd have to send the email directly from SendInvoice(), meaning to test it we'd need to send an actual email, wait for it to arrive, and write code the check the mailbox. But if we assume we have an IEmailService that works correctly, we can just test that SendInvoice() calls it with the correct MailMessage. In this case we use a mocked IEmailService to check the behaviour of SendInvoice(), and make sure it calls Send() properly. > > ... People recommend > that I use Rhino Mocks(at first I was going to try to do it without a > framework but figured might as well use it so I don' t have to relearn > lots of the stuff later). I'd really recommend not using a framework at first, and just concentrate on getting your code unit tested. If you start manually writing mocks for your dependencies, then you'll understand exactly what is happening. It will also quickly give you an appreciation of why a framework like Rhino Mocks is so useful in generating the mocks for you, and by that time you'll understand how the whole process works, and it will just be a matter of learning the syntax. As we're probably well off the topic of Rhino Mocks by now, feel free to give me an email if you want to keep chatting about this. :) Regards, David --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Rhino.Mocks" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/RhinoMocks?hl=en -~----------~----~----~----~------~----~------~--~---
