I'm at the Microsoft SOA & Business Process Conference this week, and presenting on Friday on BizTalk 2006 R2 and HIPAA Transactions. Starting bright and early on Monday morning, I'll be Twittering my progress through the day, any big announcements and any little observations. I will of course have more than one blog post from this week as well, but if you want your "live and up to date" information, then now is the time to start following me in Twitter.
If you attended either of the launch events in Dallas or Houston this week for BizTalk 2006 R2 and you'd like the slides for the content presented there, then you can find those here which contains content from: Dustin Hicks of Microsoft presenting an Overview of BizTalk 2006 R2Tim Rayburn of Sogeti on BizTalk 2006 R2 and EDI/HIPAA transactionsLeigh Sperberg of Sogeti on the Enterprise Service Bus guidance Unfortunately I do not currently have Jake's deck on AmberPoint, but if I can get a copy I'll update this post. UPDATE : I've included .PPT versions of all presentations previously only included as .PPTX for those who could not easily load PowerPoint 2007 files.
Mocking frameworks are growing more and more in popularity these days, because to some degree Unit Testing, via TDD or otherwise, has been growing in popularity. This week at the Heartland Developer Conference I gave a talk on what I call "practical" TDD. The talk goes over the basics of TDD quickly, but is really targeted at those who have tried to do TDD but found it difficult because they are not working on a team that has adopted the practice, or they are not working a project that was built to be testable. I spent a good bit of time working no what is the easiest path to help such people adopt TDD, because adoption of such good practices is far more important to me than perfection in them. As has been said many times, Good Enough is by definition, Good Enough. After a good bit of research on the subject of mocking frameworks, I have come to the simple conclusion that: This is an area that is growing still, as nearly every major framework differs on the coding approach. This is in stark contrast to testing frameworks which, to a one in .NET, all have settled on the NUnit 2.0 model of using attributes. That if you're not using TypeMock then you're just working to damned hard. Now, I'm sure my friends (and there are many) who use Rhino Mocks will believe that I must be over-stating the issue, but I tell you clearly I am not. TypeMock is not built like any other mocking framework currently available, it uses the profiling APIs and not polymorphism or encapsulation in order to intercept calls and provide return values. Let me give you just a few examples of things which TypeMock can do in a few short lines of code which Rhino Mocks simply cannot do at all. Mocking Static Methods Take the following code, and assume that we wish to mock MessageBox.Show which is a static method:private void MyCoolMethod(string msg){if (MessageBox.Show(msg) == DialogResult.OK)Console.WriteLine("OK");elseConsole.WriteLine("Not OK! Not OK!");}The following test will work perfectly to mock this call. No other hidden setup, nothing more than a reference to TypeMock.dll and the following code:[Test]public void MockMessageBoxShow(){MockManager.Init();Mock mbMock = MockManager.Mock(typeof(MessageBox));mbMock.ExpectAndReturn("Show", DialogResult.OK);MyCoolMethod("Here we go again.");// Ensure that all expectations were met.MockManager.Verify();}And with just that little code, just 4 lines dedicated to the mock, 2 of which should be refactored to Setup and TearDown methods, we can mock a static method.Not cool enough for you? Ok, fine.Mocking EventsSo you have something which expects an object to return certain events. This example does require a professional license of TypeMock, it will not work under the Community Edition, but if you need this functionality then really pay the nice folks their money.public class GUI{public string LovingCSharp { get; set; }public void Initialize(){this.LovingCSharp = string.Empty;Button button = new Button();button.Click += new EventHandler(button_Click);}private void button_Click(object sender, EventArgs e){this.LovingCSharp += "LOVE!";}}Now let's mock this up, call that event three times, and assert that our property is set correctly. [Test]public void MockFormWithEvents(){MockManager.Init();// Mock button so that we can...Mock btnMock = MockManager.MockAll(typeof(Button));// Handle all calls to add an event handler.MockedEvent evntMock = btnMock.ExpectAddEventAlways("Click");GUI frm = new GUI();frm.Initialize();evntMock.Fire(this, EventArgs.Empty);evntMock.Fire(this, EventArgs.Empty);evntMock.Fire(this, EventArgs.Empty);Assert.AreEqual("LOVE!LOVE!LOVE!", frm.LovingCSharp);// Ensure that all expectations were met.MockManager.Verify();}}SummaryThese are just two examples, and don't even delve into the whole "Natural Mocks" portion of TypeMock. Do yourself a favor, download the evaluation, they'll give you 30 days of all the features (which you can make any individual 30 days you'd like BTW) and ask yourself why you're jumping through all those hoops just to be able to mock dependencies. With this project, you don't have to create dependency injection constructors just to make your classes testable.
