When you’re server isn’t ready or is unreliable, the lack of an available connector to a datasource (Which is the role of a Delegate in CG) is not the real bottleneck of driving the UI forward. It’s the absence of data to bind to which is the real problem.

If someone was trying to mock up the delegate layer, it tells others that the encoding/decoding of data is indeterminate, whether AMF, SOAP, rest, URL Encoded, anything to do with transmission of data, etc.

If you already have a domain model that defines the VO’s on the client side, the real bottleneck of a UI is solved by creating a mock model made of hard-coded dummy data. Because this is a mock model, it’ll likely implement a common interface. When it comes time to Integration, you can easily substitute the DummyModel for one that can populated live by the delegate because it implements a common interface. This approach is more useful when trying to do unit testing on commands as your ModelLocator can return you a mock model. Unit testing the delegate is less useful as it’s just a matter or not did the data get send over the wire or not, regardless of the content of the data.

I’m aware of Mockolate (she’s pretty advanced for this topic), but TOTALLY forgot about Mockito, and never heard of your RPC stubs. These are great, thank you very much!

Yeah, I’ve done fakes too; basically save the AMF data as a ByteArray into a SharedObject, and thenceforth load the binary data. Wasn’t aware it was a pattern, haha. That link will be helpful in my consulting, thank you again!

Yep.

Our Model’s aren’t talking to the back-end, the BusinessDelegates are. The Model’s, and the ValueObjects that are stored on it are real and match the back-end Java DTO’s. So, no problem there; this is real data, no need to mock it.

When you’re server isn’t ready, or is unreliable, the BusinessDelegates become the bottleneck. This is my suggestion for how to fix it and ensure the team can move forward. Maybe I’m misunderstanding what you’re suggesting.