@Dom... and others who can help,
I have done unit testing for six plus years. I only recently decided
to
pursue some of the newer tools and techniques. I have come to realize
I
have only been doing State Testing. I am experiencing a strong
Paradigm
Shift trying to adjust to everything needed for Behavior Testing.
I think you are hinting at Inversion of Control or something like
that.
I have to admit that is one of the areas that I am still lacking
appreciation. As I understand it, if I had an interface such as the
following it would be easy to test.
interface IRadItemCollection
{
int Add(RadItem item);
void Clear();
}
But if I have the following class, it isn't easy to test?
class RadItemCollection
{
int Add(RadItem item) { /* Do Stuff */ }
void Clear() { /* Do Stuff */ }
}
I strongly hope that I am misunderstanding you here. Anyway on to the
IOC stuff. The RadItemCollection comes from am assembly in which I
don't have the code for, therefore I can't do the following.
class RadItemCollection : IRadItemCollection
Yes I could create yet another class to act as wrapper such as:
class RadItemCollectionWrapper : IRadItemCollection
{
RadItemCollection collection;
int Add(RadItem item) { return collection.Add(item); }
void Clear() { collection.Clear(); }
}
I was under the impression that Mock frameworks were used to
(well, uhm) mock the code so I don't have to write all the extra
overhead. I assume I am a overthinking this or have just missed
some simple principle that would allow me to progress.
On Mar 11, 1:55 am, DomRibaut <[email protected]> wrote:
> Hi,
> If I understand right you want to test that a view component is being
> called in a specified way and the component is not easy to test. if
> this is not the case then the rest of my opst might not apply as it is
> not an answer about Rhino mocks but more about testing interaction
> with a "complicated" component :)
>
> A way to test this interaction could be to extract an interface from
> your components and then test your componentController/presenter (your
> helper class) agaisnt those interface.
> in the production code you can make the component implement the
> interface or have a thin wrapper implementing the interface around the
> concrete component if you can't change it.
> It is now possible to send the component/wrapper using the interface
> to your helper class . If you need a Wrapper you can make the wrapper
> so dum that it is ok not to test it.
>
> collection = repository.StrictMock<IRadItemCollection>(); // note
> using an interface, has methods Clear and Add
> comboBox = repository.StrictMock<IRadComboBox>(); // has methods
> SuspendLayout etc
>
> btw, can't you use the AAA-syntax? It is usually easier IMHO
>
> Dom
>
> On Mar 9, 12:15 am, 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 -
>
> - 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.
