Hi
A good source of information about testing the presentation logic and
building a dum (not tested) UI layer is M. Fowler articles about
presentation patterns. You might want to focus om the passive view
(http://bit.ly/pMdr). You will find links to the main articles on the
page http://martinfowler.com/eaaDev/ , look the update part dated
18.07.2006
A really hands-on serie of articles on the same principles is the
serie from Jeremy Miller http://bit.ly/8728
I have been using MVP (supervising controller) with winforms and I
like it a lot because it makes thing quite easy and leave little
untested code (only the code from the UI-widget). All the
presentatrion logic leaves in the presenter. The passive view named
above goes even further but I sleep well at night with some stupid
untested code :)
> I don't see how to test that PreAdd is calling SuspendLayout
This code might be _very_ bound to the control your are using today.
So why invent a new API when you have one right here provide by your
RADControl? Does it buy you something? I push again the idea of a
wrapper implementing the interface and just forwarding the calls to
the control. You would test the interactions (order of the calls etc)
on the interface and then have a stupid wrapper forwarding the calls
class RADControlWrapper : IRADControl { // only reason to have it is
to implement the interface that is tested
public RADControlWrapper(RADControl wrappedControl){..}
public void DoSomething(){_wrappedControl.DoSomething();}
}
** Moving to another Control **
When you decide to use another control it might be worth to extract an
interface from IRADControl showing the intend of the calls (trying to
be independent of the control used) for. ex. IComboItemAdder. this
will let your client code being independent from the type of control
that you are using and you will be able to use an Adapter with the
special parts for each control.
In other words, It might be easier to start with the IRADControl
implementing all the call and splitting the interface later on when
you need to change the RADControl
IDevXpressControll : IComboItemAdder
ITelerikControll : IComboItemAdder
and so on
--
Dom
On Mar 15, 4:48 pm, BaRuSa <[email protected]> wrote:
> @Patrick... and others who are proficient with IOC, DI, etc.
>
> I like the idea of your manager class on many levels. The team has
> discussed moving away from these controls. Having manage/adapter
> functionality would ease our ability to replace these controls.
>
> The one detail I am still stuck on is that the manager only seems to
> shift the testing location and therefore shift the problem. The new
> class would make it easier to test the functionality of AddItems. I
> don't see how to test that PreAdd is calling SuspendLayout or the
> various other offending methods. It there a different method for
> testing this step works as expected?
>
> At one point code coverage was the main metric to determine whether
> the unit testing process was complete. I could imagine that reducing
> the number of calls to the SuspendLayout to one location in PreAdd
> would potentially increase code coverage by changing the ratios of
> testable to untestable code. Of course, I do wonder does the moderen
> unit test developer concern themselves with code coverage? (aka am I
> stuck on a detail that reall isn't THAT important anymore???)
>
> On Mar 13, 9:18 am, Patrick Steele <[email protected]> wrote:
>
> > I didn't read your original request closely enough to realize what was
> > going on. Rhino Mocks tracks "expectations" by intercepting calls
> > made on the mocked object. To do this interception, the mocked object
> > must be either an interface, or a class with virtual methods. It
> > looks like the "Add" method on the Rad component may not be virtual
> > and therefore, can't be tracked by Rhino Mocks.
>
> > If the methods on the Rad objects are not virtual, you can't use Rhino
> > Mocks to set up expectations. You could create an interface for a
> > that defines methods for pre and post adding of items. Then make a
> > class that implements that interface and is used by your additems
> > extension method. You can then set expectations on the interface.
> > Something like this (WARNING: really quick code follows):
>
> > interface IRadItemManager
> > {
> > void PreAdd();
> > void PostAdd();
>
> > }
>
> > Then make an object that implements this interface and works with the
> > RadComboBox:
>
> > public class RadItemManager : IRadItemManager
> > {
> > private RadComboBoxItem comboBox;
>
> > public RadItemManager(RadComboBoxItem comboBox)
> > {
> > this.comboBox = comboBox;
> > }
>
> > public PreAdd()
> > {
> > comobox.SuspendLayout();
> > }
>
> > public PostAdd()
> > {
> > combobox.ResumeLayout();
> > }
>
> > }
>
> > Your extension method should now accept an IRadItemManager. Something like:
>
> > public static void AddItems(this RadComboBox comboBox,
> > Dictionary<string, string> items, IRadItemManager manager)
>
> > Get rid of your "combobox.suspend/resume" calls and replace them with
> > calls to manager.PreAdd/PostAdd. Then you can set expectations that
> > the manager.PreAdd is called before manager.PostAdd. You could make
> > implementation seamless by adding another overloaded extension method
> > with your current signature that will call the new one and
> > automatically create the RadItemManager:
>
> > public static void AddItems(this RadComboBox comboBox,
> > Dictionary<string, string> items)
> > {
> > return AddItems(comboBox, items, new RadItemManager(comboBox);
>
> > }
>
> > Hope this helps.
>
> > ---
> > Patrick Steelehttp://weblogs.asp.net/psteele
>
> > On Fri, Mar 12, 2010 at 1:05 PM, BaRuSa <[email protected]> wrote:
> > > @Patrick:
>
> > > Using Visual Studio's "Goto To Definition" the API [from metadata] is:
>
> > > public int Add(RadItem value);
>
> > > As a newbie, I assume that since the Add function has a return value
> > > my expectation has to have a .Return(...). Is my assumption
> > > incorrect?
>
> > > On Mar 10, 9:23 pm, Patrick Steele <[email protected]> wrote:
> > >> It sounds like the "Add" method may not actually return anything --
> > >> but you've set an expectation that the Add will return an Int:
>
> > >> collection.Expect(c => c.Add(null)).IgnoreArguments().Return(0);
>
> > >> Have you tried removed the "Return(0)" clause?
>
> > >> --
> > >> Patrick Steelehttp://weblogs.asp.net/psteele
>
> > >> On Mon, Mar 8, 2010 at 6:15 PM, BaRuSa <[email protected]> wrote:
> > >> > The Rad components are third party controls that I do not have control
> > >> > of changing the way they work. I have a helper method extension that
> > >> > provides steps for frequently repeated code.
>
> > >> > public static void AddItems(this RadComboBox comboBox,
> > >> > Dictionary<string, string> items)
> > >> > {
> > >> > RadItemCollection collection;
> > >> > RadComboBoxItem item;
>
> > >> > comboBox.SuspendLayout();
> > >> > collection = comboBox.Items;
> > >> > collection.Clear();
>
> > >> > foreach (KeyValuePair<string, string> pair in items)
> > >> > {
> > >> > item = new RadComboBoxItem(pair.Key, pair.Value);
> > >> > item.Name = pair.Key;
> > >> > collection.Add(item);
> > >> > }
>
> > >> > comboBox.ResumeLayout();
> > >> > }
>
> > >> > Due the order of SuspendLayout, clearing items, adding items, and
> > >> > ResumeLayout being important I want to create an ordered test.
>
> > >> > [TestMethod]
> > >> > public void AddItems_call_in_specific_order()
> > >> > {
> > >> > RadItemCollection collection;
> > >> > RadComboBox comboBox;
> > >> > MockRepository repository;
>
> > >> > repository = new MockRepository();
> > >> > collection = repository.StrictMock<RadItemCollection>();
> > >> > comboBox = repository.StrictMock<RadComboBox>();
>
> > >> > using (repository.Ordered())
> > >> > {
> > >> > comboBox.Expect(c => c.SuspendLayout());
> > >> > comboBox.Expect(c => c.Items).Return(collection);
> > >> > collection.Expect(c => c.Clear());
> > >> > collection.Expect(c =>
> > >> > c.Add(null)).IgnoreArguments().Return(0);
> > >> > comboBox.Expect(c => c.ResumeLayout());
> > >> > }
>
> > >> > using (repository.Playback())
> > >> > {
> > >> > comboBox.AddItems(testItems);
> > >> > }
> > >> > }
>
> > >> > I receive an error at the collection.Expect for the c.Add as follows:
>
> > >> > System.InvalidOperationException: Type 'System.Int32' doesn't match
> > >> > the return type 'System.Void' for method
> > >> > 'RadItemCollection.OnInsertComplete(missing parameter, missing
> > >> > parameter);'.
>
> > >> > As I am new to using the Rhino Mock framework I don’t understand this
> > >> > error. My function AddItems doesn’t call OnInsertComplete. The test
> > >> > function doen’t call OnInsertComplete. I thought the purpose of
> > >> > using a mock framework it that the framework emits code to stand in
> > >> > place of the real code. I don’t understand why I am getting this
> > >> > error because OnInsertComplete is not being tested and should not even
> > >> > exist.
>
> > >> > I am assuming OnInsertComplete is a private function because I don’t
> > >> > have access to the function to do an Expect. The most important
> > >> > question is how do I fix my test? I tried changing StrickMock to all
> > >> > the different variations including Stub. Is there a way to emulate
> > >> > the OnInsertComplete command?- Hide quoted text -- Hide quoted text -
>
> > - Show quoted text -
--
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.
