I've read some of the older posts regarding mocking in Csla apps, and most of the discussion was around mocking the data access, and they are also very old discussions and things have changed a lot since then. So...
My company is writing our first SL4 app, using VS2010, Csla 4.0 (also a first for us). We're using the MVVM pattern and are thinking about unit testing the VM...presumably its interactions the the client-side BOs. This seems like a useful place to use mocks, so that the entire async behavior is eliminated...after all, all I want to test are the VM methods used as an interface between the UI and the client-side BOs. This statement may be totally non-sensical as I haven't really looked into the VM code (someone else is prototyping that), so if it is, I'll go back and learn some more before pursing this idea.
I don't want to use a mocking framework...it seems (conceptually) easy enough to create interfaces for my BOs to implement and then I can write simple mock object that implement those interfaces and have them return hard-coded data. This is easy enough to do for simple property types, but I'm having trouble figuring out how to define child collection interfaces. I presume my mock collections cannot inherit from Csla base classes, or can they? Clearly the mocks would avoid calling any data portal calls, but would that be sufficient? Or would implementing something like IEnumerable work?
Has anyone done this, or is it brain-dead?
TIA
It is actually almost impossible to create a meaningful mock of a CSLA business object. The reason is that the mock object would need to simulate all the data binding behaviors exactly and completely or you couldn't establish correct behavior of the consumer (in your case the viewmodel).
Personally I fail to see the value in mocking the business object - which is why I always focus on enabling mocking of the DAL. Just let the data portal invoke your mock DAL so your viewmodel tests (and/or business object tests) are working against known behavior and data.
The harder thing, in reality, is to mock the viewmodel such that it interacts with no actual UI elements.
Copyright (c) Marimer LLC