Jim, I'm not 100% clear about where you are considering adding ObjectScope in an *overloaded constructor*, but I would recommend that you do not do it, this technique/trick has come to be known as *"bastard injection"* and it is a code smell.
You are on the right track by injecting ObjectScope, but I would seriously recommend *NOT overloading the constructor,* but rather have a single constructor which is provided with all of the class' dependencies, there are various reasons why you should not use *bastard injection* if you can avoid it (which generally means if it's a class that you have written or rather, when the code used is not generated by an automaton), the most important of these reasons is that you will most likely be using the class differently under test than you will in released code; which then beggars the question of what your tests are actually testing ... turns out that usually they are testing code put in place specifically to enable testing ... which means that you will get false positives/negatives, you could also find that in your released code you might have some dependency issues since the code has been modified in some "hacky" manner in order to use the injected dependency under test, or to new it up somehow in live. Using Rhino, *you will not be able to mock your CRUD service unless it's members are instance and virtual*. In my opinion, the CRUD service should not be static anyhow ... there are other objects that have dependencies upon this static class, make that dependency explicit in your design (i.e. inject an instance of the CRUD service). There are times and places for * statics*, but most of the time they are not where and when they are being used ... something which I find quite annoying about ReSharper is its constant insistence upon informing one that a member can be made static. So the points that Patrick has raised are valid, however I'm not entirely sure of what the real issue is that needs attention ... sometimes I'm a bit dim see? On Thursday, September 13, 2012 2:25:34 AM UTC+1, jdl wrote: > > All, > > I have been going back and form with the team at Telerik that put out > JustMock as I am evaluating several mocking frameworks right now. I spend > most of my day working in business layer logic in IIS hosted WCF services. > I am attempting to break my SQL server dependecy in my unit tests by > mocking out the db context. A Rhino Mocks users essentially achieved what I > am looking for here in 2009 using an old implementation of OpenAccess here: > http://www.reversealchemy.net/blog/2009/03/17/exploring-telerik-openaccess-unit-testing-your-business-logic-using-rhino-mocks/. > > The issue is several fold but the root of it is that OA > has fundamentally changed its implementation since then and I cannot seem > to get it to jive quite right with either JustMock or not Rhino Mocks. I > have emailed the original author of the article to see if he has an updated > example and will post his response here should he respond. Ultimately what > it boils down to is that I have methods that perform business logic that > may or may not add/update entities (hacked example code below). What I am > trying to achieve (and it simply may not be possible given my end goal and > I apologize as I am relatively new to mocking) is to break the dependency > on a DB on the other end while still leveraging the code as if it were (i.e > Add an entity to the context but not actually commit it OR when an add > occurs on an entity whose ID is a uniqueidentifier (guid), return a new > guid to simulate success which allows the update method to use that > entity's guid to perform the update operation). > > Please let me know if you need a more extensive code example. I am hopeful > that Erik's post and the sample methods below will highlight what I am > trying to do, something that I have not yet successfully conveyed to > Telerik. > > public static Guid AddUser(string name, int legacyId = -1) > { > try > { > using (var model = new VerifyModel()) > { > User userEntity = GetUserEntity(name); > > if (userEntity != null) > { > return userEntity.Guid; > } > > var newUser = new User > { > Name = name, > LegacyId = legacyId > }; > > model.Add(newUser); > model.SaveChanges(); > UserContainer.Instance.Refresh(); > return newUser.Guid; > } > } > catch (Exception exception) > { > ErrorLogWriter.Write(MethodBase.GetCurrentMethod().Name, > exception); > } > > return Guid.Empty; > } > > Update method handles optimistic verification exceptions but at the end of > the day simply performs a sql update. > > public static bool UpdateUserDetails(Guid userGuid, > IEnumerable<ElementAttributeValues> elementAttributeValues) > { > try > { > var historyEvents = new List<string>(); > > using (var model = new VerifyModel()) > { > var user = model.Users.SingleOrDefault(p => p.Guid == > userGuid); > > if (user == null) > { > return false; > } > > var enumeratedElementAttributeValues = > elementAttributeValues asList<ElementAttributeValues> ?? > elementAttributeValues.ToList(); > > try > { > > UpdateUserEntity(enumeratedElementAttributeValues, ref user, ref > historyEvents); > > model.SaveChanges(); > } > catch (OptimisticVerificationException > optimisticVerificationException) > { > ErrorLogWriter.Write(string.Format("An optimistic > verification exception occured in {0} and the commit will be retried. The > error message is: {1}.", > > MethodBase.GetCurrentMethod().Name, > > optimisticVerificationException.Message)); > > model.Refresh(RefreshMode.OverwriteChangesFromStore, > user); > > // retry update > > UpdateUserEntity(enumeratedElementAttributeValues, ref user, ref > historyEvents); > > model.SaveChanges(); > } > > foreach (string historyEvent in historyEvents) > { > HistoryWriter.Write(userGuid, historyEvent); > } > > return true; > } > } > catch (Exception exception) > { > ErrorLogWriter.Write(MethodBase.GetCurrentMethod().Name, > exception); > } > > return false; > } > > > -- You received this message because you are subscribed to the Google Groups "Rhino.Mocks" group. To view this discussion on the web visit https://groups.google.com/d/msg/rhinomocks/-/dEXYd5R9ZjQJ. 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.
