Santosh Benjamin's Weblog

Adventures with AppFabric, BizTalk & Clouds

Archive for the ‘Patterns’ Category

Tales of ‘Mock’ing birds and OO design

with one comment

In my previous post, i talked a bit about using the Model View Presenter in the ASP.NET project im doing and the videos of Jean Paul Boodhoo and others that gave me the necessary material to do the work.

The thing that most impressed me with JPB’s videos was the use of Mock Objects. I have been aware of them for a long time but never had any reason to use them, being primarily in the Biztalk world. I have recently read about using IoC/DI & mocks in pipeline components and custom adapters but have never had the chance. I was pleasantly surprised to find that i had quite underestimated what can be done with mocks. I always saw them as ‘fake’ data suppliers and didnt realise how you nicely can test the behavior of the system with them. I’ve adopted them wholesale now and have quite fallen in love with the approach of mocks and depedency injection. If only we could unit test Biztalk like this!!

I decided to keep things simple and have used only NMock2. The best article i found is in MSDN Magazine – Exploring the Continuum of test doubles. This is a really good resource explaining the range of different types of test helpers- dummy data, fakes, stubs, mocks and so on. I had a brief look at Rhino Mocks and it seems very powerful but reading through the material on the new kid in town , MoQ, i think i will go with MoQ in future as i dont quite get the point of the Record and Replay syntax of Rhino and others. TypeMock seems quite brilliant too with its ability to mock concrete classes as well which, IMO, is a boost in brownfield systems that dont have (m)any interfaces or opportunities to inject things into the system under test. I dont think MsTEST has any mocking capabilities yet, but maybe there is ..

But the time i spent researching mocks brought to light just how much (mostly) pointless academic debate there is about these things. There are heated debates on blogs about whose approach is ‘purer’, classic TDD vs. mockist TDD and all sorts of things. To some extent, these discussions are educative, but then they soon descend into weird stand-offs which does no one any good. This is why i have taken a liking to the approach in MoQ – mainly because Daniel Cazzulino (kzu) and the other Clarius chaps who started it seem very pragmatic rather than being stick in the mud purists. Check out some of Daniels posts here , here and here ) These tools are all good, Rhino, NMock2, MoQ, TypeMock and we should be highlighting their strengths and applicability to different situations and getting more people using them rather than arguing over whose approach is the right one. Lets face it, NO ONE is going to agree on what ‘correct’ OO design is (if there is such a thing). Interfaces are great, but they can be overused. Classic TDD state based tests are great but only for state testing.. Mocks are great but just for behavior. There are those who think that even using mocks is a ‘smell’ Heck, to some folk, using X is a ‘smell’ and to others not using it is a ‘smell’. Frankly, these debates stink. 🙂

If i hadnt started seeing a glimmer of light with my simple forays into NMock i would have avoided mocks altogether, actually, i would even avoid TDD altogether if i were to pay much attention to these silly arguments and posturing.  If you can write all your tests first, good. I’m happy for you. Just because i write some tests before and some tests after, doesnt mean i care less about my code. And yes, according to me its perfectly fine to buy/use a tool that will generate unit tests for my code because, at the end of the day, i want the code to be tested  (actually i dont use any test generators… yet…) . I agree theres less code to write when you write the test first (or at least stub out your expectations) and you’re more likely to write better quality code in small increments but when you inherit a project do you care what came first, as long as there is a good set of tests?

Anyway, enough of my rant..but hey, i do feel better for having got that off my chest!!. So, back to the point, i used IoC quite a bit, injecting views into presenters, service agents into presenters, services into service agents etc and ended up covering the codebase with a wide variety of tests even before i wrote a single aspx page. I enjoyed the opportunity to think through the behavior of the system in a white box manner rather than just relying on state based tests. I do have quite a few state based tests now but only wrote them when i had exhausted all tests on behavior and had to check the exact return values.

Having done all this, i was overjoyed to go back to the old orchestration designer when i had to add a couple more features to one of those backend services. It seemed like a trusty old friend not like those weird GridViews and their datasource pals!!! … Mocks are cool, maybe we will see more of them in the biztalk world, but for me personally, i cant wait to finish off the ASP.NET and go back Biztalk and WebServices.


Written by santoshbenjamin

August 2, 2008 at 12:49 AM

A brief foray into the world of ASPX and MVP

with 2 comments

Whew!! This has been a long time since i managed to put pen to paper as it were and post anything here. I’ve been spending a few weeks away from Biztalk in the murky world of ASP.NET. Its been an exhausting time but a great learning experience and lots of fodder for a set of blog posts. So, whats a Biztalk guy doing with ASPX then?

Well basically once we got the Oracle adapter working somewhat decently and linked up the needed systems, we were tasked with adding some aspx forms to interact with a couple of the services. Having volunteered for the task back when it was originally envisaged as a one man project (featuring yours truly) I had to come good on my promise. It is only a small aspx system, 4-5 pages with a few grids and data displays linked to the two backend services.

I could have gone down the standard webforms route, but with our main portal being implemented with Model View Presenter, i decided that to keep things consistent I would have to use the MVP pattern. Couldnt choose MVC though cos its still all .NET 2.0 and MVC isnt RTM anyway so that was out. The two main resources that kickstarted my foray into the MVP world were Jean-Paul Boodhoo’s videos (MVP, TDD-1 and TDD-2) for DotNetRocks TV as well as his excellent article on the same subject for MSDN Magazine. I highly recommend watching the DNRTV videos and although the TDD ones pre-date the MVP show, its better to start with the MVP show cos JP had introduced MVP in the TDD videos and sparked an interest and that led to him doing an entire show on MVP. I also spent some time with the videos on Polymorphic Podcast – their Design Patterns Bootcamp- MVP series. All of these are excellent.

I found myself leaning more towards the Passive View approach that JPB favors rather than the Supervising Controller which is the approach shown in the Polymorphic Podcast set. It seemed to me, when i first saw the show, that keeping the view to a complete minimum was definitely the way to go. Ironically, over the course of the project i found that i ended up doing more of the Supervising Controller particularly because rendering the gridviews play a major part in the system and so theres a huge amount of code in the view. Not business logic, mind you, but lots of display logic, databinding and so on. I think the Passive View approach is rather hard to do well when you have a fair amount of databinding to do and i really dont think the presenter should know that the View is using a grid or any specific control as it would make them too tightly bound.

Since there isnt any business logic as such , I elected to use a DTO library to pass data through the view – presenter – serviceagent layers. The serviceagent wraps the two proxies of the webservices and maps their structure to the simpler DTOs. It took me sometime to get my head around the page lifecycle and the way databinding works with custom object collections. Basically the gridView doesnt work well with the MVP (at least, when using Object data sources) because in the webforms world, the view is king and takes control immediately. So if you specify an object data source, the grid will immediately call into it and try and get the data from wherever the object points to , but in the MVP, we want to push the data into the grid so the grid wont get anything by simply initialising the collection. So I ended up having to dynamically databind and before that to serialize the collection into a DataView so that paging and sorting the grids became simpler. I didnt want to implement all that kind of paging and sorting logic into my DTOs.  I read David Haydens article on using the WCSF Object Container Data Source when using grids with the MVP approach but by then i had got the dataviews to work so i didnt bother trying that out. Will file that away for future reference.

I can see why people struggle with the webforms model and why the MVP and MVC approaches are gaining so much popularity. Declarative stuff is alright but only as long as you buy into it wholesale and are willing to lose some control over the way the system works. Yes, it works for lots of systems, but personally i prefer to take more control over my system and the MVP gives me that. Im quite looking forward to trying my hand at MVC (only a little bit).

One thing my experience with the gridView and the hours i spent trying to style it exactly to match the mockup screens that formed the spec taught me was that CSS and layout are not my cup of tea. I still havent got the pages to look like they are supposed to. They work and in a very robust way  (yeah, i would say that wouldnt i?) but they dont look impressive. The reason im confident about the system will be dealt with in the next post.

So, in summary, IMO, the Model View Presenter is great but hard to do right.

Written by santoshbenjamin

August 2, 2008 at 12:35 AM

Posted in ASP.NET, General, Patterns