Bill, I am the first to admit that when it comes to mocking it is a fairly grey cloud. I work in a large development group but run my own team and we put out some fantastic software that is used both internally and externally to the company. I am always looking to advanced my knowledge and the art and mocking is always something I wanted to spend the time to know, appreciate and embrace. The "wall" that I am hitting is that most of the times these days I am working deep in WCF web services, yes with POCO's and the first real world example that I want to try this out out is seemingly a complicated one.
To be completely honest, this whole process started because I wanted to break my dependency on a dev sql database where my unit tests were purging the tables before each test run as it constrains me with continuous integration as well as other devs might be looking at something else in the data and it be pulled out from underneath them. Would it be helpful to provide a sample? I would be happy to do so but do not want to overstep my welcome. I had written a sample for Telerik a few days ago that is a barebones WCF service that simply supports the adding and updating of a user object that as designed today, using OpenAccess, requires there be a live SQL db on the other day. An idea I was kicking around with respect to mocking ObjectScope was to also mock the transaction which would allow me to transactionally keep it open over the life of the unit test and leverage FlushChanges() which will move items onto the queue to be committed to SQL (which has the benefit of also supplying the autoinc ID's for the POCO's) but never calling SaveChanges() which would commit the operation. I realize this is going the opposite direction of breaking SQL dependency (actually increases it) however for this instance, it would suit my needs. At the end of the day I am just trying to add another tool to the toolbox :) Thanks, Jim On Friday, September 14, 2012 3:38:45 AM UTC-4, bill richards wrote: > > Further to my initial response .... > > I think that maybe *the dependency graph is your issue.* I think what you > are trying to do is to test your POCO objects, which you are finding > difficult to do because in the current design there are some hidden, *hard > coded volatile dependencies*. > > Once you have broken these dependencies your problem will disappear (at > least I think that's the case, if I've interpreted the combination of your > question and the Telerik link you posted). > -- 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/-/FS1ZaVNAy_4J. 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.
