tag:blogger.com,1999:blog-18140762.post6701700645973070098..comments2008-10-10T02:20:46.432-07:00Comments on AssertionFailed...: Getting to the root of a problem...Shyam Seshadrihttp://www.blogger.com/profile/17328035298561522443noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-18140762.post-57349929988829475172008-07-20T09:59:00.000-07:002008-07-20T09:59:00.000-07:00@akuhn: Thanks for the great reply. Example driven...@akuhn: Thanks for the great reply. Example driven testing seems like an interesting approach, especially if you prefer to do TDD or EDD. But still, as you mentioned, the House test being shown as white due to a failed dependency means you wouldn't know if House works or not. There might be additional failures which you wouldn't catch until you fix the problem in Kitchen. With mocks on the other hand, Kitchen test fails, we know kitchen has a problem, while the House which uses a mock, and thus probably wouldn't be having the bug allows the House test to pass. Just my thought on the subject.<BR/><BR/>Well, yes, sadly we are not yet at the level of line level assertion failures. Thought generally, I try not to have too much same class method dependencies. Usually those kind of methods are private as well. And technically, you could mock out public methods with EasyMock, I believe.Shyam Seshadrihttps://www.blogger.com/profile/17328035298561522443noreply@blogger.comtag:blogger.com,1999:blog-18140762.post-15375870371086942602008-07-13T06:44:00.000-07:002008-07-13T06:44:00.000-07:00First of all, thanks for the answer on my blog and...First of all, thanks for the answer on my blog and addressing my comment in a full blog post here. Let my structure this comment in two parts. First I will present example-driven testing, an alternative to mock-based testing. An alternative which I personally find more pragmatic. Ads second, I will show why we are still not at the level of source-line assertion failures.<BR/><BR/>1)<BR/><BR/>Given your House with a Kitchen, you propose to use a mock kitchen to test the house. However, setting up a mock can be quite some work. And why do that work if somewhere else we already do all the work of creating a working kitchen? Yes, if only there would be a <I>return value at the end of the kitchen tests</I> we could use that instead of the mock. <BR/><BR/>This is exactly what we do in JExample (a JUnit extension): we avoid all the mocks, because our test methods can have return values and dependency injections. Let me give an example<BR/><BR/>@Test<BR/>public Kitchen testKitchen() {<BR/> Kitchen k = new Kitchen;<BR/> // ... assertions<BR/> return k;<BR/>}<BR/><BR/>@Test <BR/>@Depends("testKitchen")<BR/>public void testHouse(Kitchen k) {<BR/> House h = new House(k);<BR/> // ... assertions<BR/> return h;<BR/>}<BR/><BR/>When executing testKitchen, the framework caches the return value: an example kitchen! When executing testHouse this example is injected as invokation argument in the test call.<BR/><BR/>If however testKitchen fails, the framework reports testKitchen as red and testHouse as white (ie failed due to dependency. Thus pin-pointing us to kitchen as the source of the failure! <BR/><BR/>Example injection is also very handy when testing different states of the same instance under test. You just inject the example from one test method to the next, thus testing all different states.<BR/><BR/>2)<BR/><BR/>Still, whether using mocks or examples, we are still not level of source-line assertion failures. Why? Even if you know the MUT (method under test) there is no bijective, ie 1:1, relation between methods and test-methods.<BR/>Given the method under test delegates to four private methods (ie 1:n), where is the bug the test fails?<BR/>Given two methods under test delegate to the same private method (ie n:1), where is the bug if only one fails? <BR/>EzUnit by Friedrich Steimann addresses these issues by analysing both the static and runtime coverage of tests and comparing it to each other.<BR/><BR/>But alas, their tool has no example injection :)akuhnhttps://www.blogger.com/profile/17211501021299556583noreply@blogger.com