Stub not working on a concrete class in code

[Peter Finch]

Hello All

Please don't roll around laughing, please.

I have this code in some code I am trying to test and I want to mock it out so that he.SaveEntry does not get called.....

Dim he As New HistoryEntry(doc, historyentry)
he.SaveEntry()

This is what I am trying to mock it out with but you guessed it SaveEntry() gets called and you end up in the database (scream).   Not a good place to be in a unit test.

Dim historyEntry As IHistoryEntry = MockRepository.GenerateMock(Of HistoryEntry)(parentContent, "test")

historyEntry.Stub(Sub() historyEntry.SaveEntry())

The background to this is that I am trying to see if I can unit test this code at all.  There is a huge amount of other stuff that I have mocked out and it's not nice.

regards

Peter

[Patrick Steele]

Is SaveEntry marked as virtual (overridable)?

---
Patrick Steele
http://weblogs.asp.net/psteele

--
You received this message because you are subscribed to the Google Groups "Rhino.Mocks" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rhinomocks+...@googlegroups.com.
To post to this group, send email to rhino...@googlegroups.com.
Visit this group at http://groups.google.com/group/rhinomocks.
For more options, visit https://groups.google.com/d/optout.

[Peter Finch]

Thanks I had already made it overridable.  Still no joy. One of the first things I checked.

When I debug the he variable is not proxied so I can tell something it not working quite right

Things I can mockout look like this......

IDocumentProxye30b840b5a094ea38ec664b39a7d4e17

History entry looks like this, which is not proxied

Core.BusinessLogicLayer.HistoryEntry

I am doing something deeply wrong,i think.

[Steve Bohlen]

You'd probably have to share/post the entirely of the test that doesn't work (and the class under test).

Else, I'd recommend trying to repro this in a brand new test with a brand new class under test, in an attempt to find "the simplest possible combination" that can repro your issue.  Start simple and then introduce one by one each of the characteristics of the HistoryEntry class until you discover what is causing this behavior.

-Steve B.

---

From: Peter Finch
Sent: ‎11/‎19/‎2014 4:45 AM
To: rhino...@googlegroups.com
Subject: Re: [RhinoMocks] Stub not working on a concrete class in code

[Peter Finch]

I'll give that a go.  I will just try to test HistoryEntry on it's own to see what happens.

Many thanks

[Reginald Blue]

Not sure if this will be helpful or just noise, but, generally speaking what I try to do when I'm tackling the issue of mocking data access components is that I encapsulate the data access inside another layer.  Typically I call the class FooDataProvider and implement an interface for it.  The method should take the search parameters for get calls and return only "local" objects (i.e. it shouldn't return DataSets or framework generated objects) and should take "local" objects for "Save" calls.  Inside the data provider, it should do all the translation between your app code and the data provider.  This provides full isolation from your data layer (i.e. abstracting away from where data is coming from), but most importantly, it provides you the interface you need for mocking.

Again, not sure if that helps or if that's just noise, but I thought I'd throw that out there for consideration.

On Wed, Nov 19, 2014 at 7:58 AM, Peter Finch <peter...@hotmail.com> wrote:

I'll give that a go.  I will just try to test HistoryEntry on it's own to see what happens.

Many thanks

--

[Steve Bohlen]

Possibly noise, but certainly excellent advice all the same :)

-Steve B.

---

From: Reginald Blue
Sent: ‎11/‎20/‎2014 5:45 PM
To: rhino...@googlegroups.com
Subject: Re: [RhinoMocks] Re: Stub not working on a concrete class in code