tag:blogger.com,1999:blog-2724692278714295115.post5850688588456457736..comments2023-06-05T03:36:07.247-07:00Comments on Richie's World: Unit Testing CSLA with Type Mock IsolatorRichard Allenhttp://www.blogger.com/profile/03057437496497128384noreply@blogger.comBlogger8125tag:blogger.com,1999:blog-2724692278714295115.post-61236948225849759352012-02-13T03:44:33.664-08:002012-02-13T03:44:33.664-08:00Unfortunately I do not know of a free alternative ...Unfortunately I do not know of a free alternative to TypeMock - although I believe that Telerik's JustMock might provide similar behaviour but that is not free either. If you do find one then let me know :-)Richard Allenhttps://www.blogger.com/profile/03057437496497128384noreply@blogger.comtag:blogger.com,1999:blog-2724692278714295115.post-58119433370430851832012-02-10T03:02:49.124-08:002012-02-10T03:02:49.124-08:00Is there any other Mocking framework you can use b...Is there any other Mocking framework you can use besides Type Mock Isolator that is for free?Donny Brascohttps://www.blogger.com/profile/05988919632335140929noreply@blogger.comtag:blogger.com,1999:blog-2724692278714295115.post-15535124413031673412011-01-07T10:21:44.235-08:002011-01-07T10:21:44.235-08:00Hi Rich,
Long time no speak; I hope you are well....Hi Rich,<br /><br />Long time no speak; I hope you are well.<br /><br />I too am continuing to struggle with the best way to unit test, because of data access. I think what Dave.Erwin said is relevant not (just?) because of testing the data access, but because of creating an object to test.<br /><br />I think what is 'hidden' in your blog is that Employee.NewEmployee <i>could</i> perform data access. In this instance I am guessing it does not. But if you have to hit the database to create a new object, that's where you have to mock out the data access.<br /><br />I really don't want to go to the trouble of complicating the architecture with interfaces, DTOs and multiple data access layers, it's just not worth the extra complexity in our environment. But I do want to deliver a good answer for our guys to use in all instances.<br /><br />Is it only/mostly validation and authorisation rules that you ever test? Ironically, the thing that almost always fails for us after object changes is the data access - incorrectly named SP parameters or missing parameters! Er, hang on, isn't that the bit we are trying to avoid running ...!AndrewHnoreply@blogger.comtag:blogger.com,1999:blog-2724692278714295115.post-81851883601069047572010-05-21T02:08:09.075-07:002010-05-21T02:08:09.075-07:00If you take a look at my next post on using Linq2S...If you take a look at my next post on using Linq2SQL to validate data access: http://richallen.blogspot.com/2009/04/using-linq-to-sql-to-validate-data.html, this explains a way in which you could simply use Linq2SQL to insert a known row into your database in the above case we would insert an employee with the required test email address, then action your command object, then assert that the result of the command object is true or false depending on what your expectation of the test is.Richard Allenhttps://www.blogger.com/profile/03057437496497128384noreply@blogger.comtag:blogger.com,1999:blog-2724692278714295115.post-11094865234006354502010-05-21T01:57:18.757-07:002010-05-21T01:57:18.757-07:00How do you then test that the command is actually ...How do you then test that the command is actually working correctly?hagashennoreply@blogger.comtag:blogger.com,1999:blog-2724692278714295115.post-82677145563929646192009-04-30T10:51:00.000-07:002009-04-30T10:51:00.000-07:00I managed to solve the problem 5 minutes after I p...I managed to solve the problem 5 minutes after I posted my last comment (of course). Turns out I missed faking out a sql command object and that was causing a nullreference exception.<br /><br />I am able to fake everything so that I can feed a SafeDataReader into my DTO. Your post and Phil Haack's StubDataReader (http://bit.ly/C8QLf) helped put the pieces together. I had to make a change to wrap _sdr = new SafeDataReader(Command.ExecuteReader()); in a method before I could get my fake SafeDataReader in place. Still working on why that was needed. Swap.NextInstance doesn't seem to work in that case.<br /><br />Really just pushing it this far to learn more about using TypeMock in different situations. I'm still not sure that the test I'm writing accomplishes much.Unknownhttps://www.blogger.com/profile/07124953079600240200noreply@blogger.comtag:blogger.com,1999:blog-2724692278714295115.post-21351795776281409062009-04-29T03:23:00.000-07:002009-04-29T03:23:00.000-07:00I don't think I shall be testing into the DAL expl...I don't think I shall be testing into the DAL explicitly but I will be performing tests that will execute data access logic i.e. expect to set values in the database, and then use a Linq To SQL data context to test whether the values have been set as I expected.<br />I would recommend using this approach of a LINQ to SQL data context as part of your DAL validation tests, it is really easy to setup and allows you to quickly verify that the stored proc you are calling is actually setting the values you expect it to without the additional need to write plumbing logic for the tests.<br />I shall try and get a blog post written on how to get it configured.Richard Allenhttps://www.blogger.com/profile/03057437496497128384noreply@blogger.comtag:blogger.com,1999:blog-2724692278714295115.post-883039114212913042009-04-28T11:29:00.000-07:002009-04-28T11:29:00.000-07:00Thanks for the post. It clarified a couple of thin...Thanks for the post. It clarified a couple of things for me. As we've discussed "drawing the line" is my difficulty. I've been stuck the last day or so trying to test down into the DAL. Trying to mock the DAL to return a SafeDataReader seems impossible and until I read this I hadn't thought about the reflection aspect of CSLA preventing it from working. So the isolation wouldn't carry through from DataPortal.XXX to DataPortal_XXX. TypeMock can do alot but maybe not quite that much?<br /><br />That being said it may be that I'm pushing the test too far down. I currently use a pretty standard DAL (no NHibernate etc.). It fills in a data transfer object which is returned to the business object. I'm setting it up so that I can swap out the DAL in the future. I am in the process of migrating my app to the DTO idea, most of it has the DAL directly in the BO. I'm thinking that the tests should go no further than mocking the call to the DAL and returning a DTO. Not sure what I'm really going to gain by testing into the DAL.<br /><br />Based on the reflection issue it would seem that my older BOs that have the DAL in them cannot be tested. All the more reason to get them over to DTOs.<br /><br />How far in are you taking your tests?Unknownhttps://www.blogger.com/profile/07124953079600240200noreply@blogger.com