Subject: Re: Re: Test first? or Stub first? - msg#00236

Previous Message by Date: click to view message preview

Re: ** How to test objects that depend on other objects with mock objects **

I finally have time to respond. So said Kirill Maximov on 2003-01-28 -------------------- >On 0, "J. B. Rainsberger" <jbr@xxxxxxxxxxxxxxxxxxx> wrote: >> So said Kirill Maximov on 2003-01-27 -------------------- >> >> <snip /> >> >> How can I switch the CONFIG_FILE_DIRECTORY value for testing when >> its >> >> in the constructor? >> > >> > I'd use such a trick: >> > >> > String basePath = System.getProperty("CONFIG_FILE_DIRECTORY"); >> > if (basePath == null) >> > basePath = ServiceResources.CONFIG_FILE_DIRECTORY; >> > >> > Hope, this helps. >> > I don't think that creating a public constructor for singleton >> > only for testing purposes is Good Thing. >> >> A matter of taste. To me, there's no such thing as "only for testing." >> This implies that testing is not important, when actually it is >> all-important. > > I don't agree about matter of taste. I'm convinced that one should not > try to increase visibility or add helper methods to ease testing. > And we should try as we might to avoid such tricks. Yes, we should avoid such tricks; however it is wise to add them in, get the test to pass, then refactor the new method out. Singletons are bandages. We need to examine the wound. The Programmer Test that adds methods to a class exposes the wound so we can clean it and let it heal. > Recently I had to rework a bunch of my tests when some previously tested > methods become private. And after such refactoring I revealed that > my tests become more clean and understandable. Good point. The quick green bar is what's important, though: make it run, then make it right. If we have to add a constructor for a while to make that happen, we do; then we figure out how to get rid of it. Better the constructor be there with a passing test than no constructor and no passing test. The ideal situation is a passing test and no constructor. Refactor to that point. >> If you read between the lines of my original reply, though, the deeper >> question is, "Why a singleton?" :) > > Sorry, I wasn't clever enough to read between lines :). But > this is quite another thing - we should keep design testable > and here I completely agree with you. Singletons are not very > suitable for testing. I always question singletons. :) J. B. Rainsberger, President, Diaspar Software Services Let's write software that people understand. http://www.diasparsoftware.com/ telephone: +1 416 791-8603 All correspondence (c) 2002 Diaspar Software Services. If you want to use it, just ask; don't steal. To unsubscribe from this group, send an email to: junit-unsubscribe@xxxxxxxxxxxxxxx Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

Next Message by Date: click to view message preview

Re: Re: ** How to test objects that depend on other objects with mock objects **

So said tobemligado <jasbell@xxxxxxxxxxxxxx> on 2003-01-27 -------------------- >Hello. > >REGARDING: "Q: Why is ConfigManager a singleton?" >==================================================== >Its a singleton because it needs to hold some state (so I would like >an instance), its state is to be referred to throughout the uptime of >the app, and finally it is called and used by several objects in the >system. Also, like I said, I want to say "ConfigManager is not valid >until its state (the other objects it loads) has also been >successfully created". Is there no object in your system that can hold a reference to ConfigManager and make it available to the rest of the system? >REGARDING: Your answer: >I did not originally do what you suggested with the second public >constructor because other members of my team will see it and use it >if they dont know better. I feel its like "changing the house to fit >the door". That's understandable. Read my other words on the topic: first get it to work, then refactor to what you really want. >I will now read the article you suggested Thanks. J. B. Rainsberger, President, Diaspar Software Services Let's write software that people understand. http://www.diasparsoftware.com/ telephone: +1 416 791-8603 All correspondence (c) 2002 Diaspar Software Services. If you want to use it, just ask; don't steal. To unsubscribe from this group, send an email to: junit-unsubscribe@xxxxxxxxxxxxxxx Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

Previous Message by Thread: click to view message preview

Re: Re: Test first? or Stub first?

"J. B. Rainsberger" wrote: > So said Curt Sampson on 2003-01-24 -------------------- > > >...I find my test cases often don't parallel the particular >methods > of a class. They test the typical usage patterns of a class, instead. Hmm. That strikes me as a key point. In essence, test construction should follow definition of use cases? Or words to that effect? I confess that although I'm "infected", I'm having a hard time actually generating tests for anything other than individual functions. That has been helpful all by itself, but I've got to get better at imagining fixtures and hanging tests off of them. I read TDD by Example, and enjoyed, but somehow I'm still missing that flash of insight that tells how to write the test first. (Too many years sitting in the saddle backwards, I suspect.) Is thinking about "use cases" a profitable approach? To unsubscribe from this group, send an email to: junit-unsubscribe@xxxxxxxxxxxxxxx Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

Next Message by Thread: click to view message preview

Re: Re: Test first? or Stub first?

So said steffen.gemkow@xxxxxxxxxxxx on 2003-01-22 -------------------- >JBR, > >> From: "J. B. Rainsberger" <jbr@xxxxxxxxxxxxxxxxxxx> > >> I'm not sure why writing the test before the stub provides more >> documentation than writing the stub before the test. > >All this is about "tests documenting the intentions behind the code". >What I ment by "documenting aspect" does not depend on which >comes first, but if tests and app are in sync. To keep them in sync >is much more easy, if one is the base for generating the other. <snip /> If I understand you correctly, you're trying to make the tests better documentation for the behavior of the system. Your concern appears to be that as we refactor the system, the tests become less of an indicator of the structure of the application, so that finding the tests for class X becomes difficult. Immediately, I react by saying, "Don't look for the tests for class X; look for the tests for behavior Y. Those tests should remain easy to find, since the name of the behavior doesn't necessarily change when the structure of the code changes." Without a specific example, I can't say more. When we refactor the code, we often need to change the corresponding tests. We should take as much care in refactoring the tests as the code, so that it remains easy to find the tests. >Imagine you want to add some new feature to an application >with this kind of tests in three years from now. You need to >modify some code and maybe you need to use some >existing code too. Then you want to understand, what the >intention behind those portions of code was. You want to >understand the methods you are about to modify/use. >Yes, you can search the tests for uses of those method. > >When I want to get an idea, what the method "xyz" is >supposed to do, I prefer to look at "testXyz". That is what >I ment with the "documenting aspect" of tests that follow >the structure of the application. I'll admit that I don't have as much experience in that regard -- I haven't worked on a project where the tests have been difficult to find because the code has been refactored away from the tests, even though the tests still run. For Programmer Tests, I can't imagine that that's even possible. For Customer Tests, I would never expect to find a CT by looking for a method name; I would look for the name of a use case or transaction script or feature. >JUnitDoclet allows re-generating, so it's not much work >to keep tests and app in sync. Regenerating what? Does it regenerate test stubs? Do I need to reimplement my test?! >> Also, if you haven't written the test, then how can you be sure that >> the stub: >> >> 1. ...has the proper signature? >> 2. ...is named well? >> 3. ...should be class- or instance-level? >> 4. ...is written on the appropriate object? > >At that point I'm not sure either. But with the skeleton of >the application method in place, one can use the full power >of the IDE. I'm using JUnitDoclet together with IDEA. <snip /> I admit that since the IDE makes it easy to "fix mistakes", we have the freedom to make more mistakes and not pay as much of a price; but still, nothing beats thinking about it first. I would have to try writing the stub, then the test, then making it pass, in order to comment further. Since I'm not working on any big projects these days, I'm not sure I'll learn enough to make the experiment worthwhile. :) >> Generally speaking, you don't really know these things until you write >> test code, which is really just sample client code, look at it, >> evaluate it and move on. In general, it is when one sees it "in print" >> than one really looks at it carefully. Writing the test first >> guarantees this, while writing the stub first does not. > >I consider the stub to be flexible when implementing the test. >There is not much of a difference, except we are using >different supporting features of the IDE. You're right. You're willing to guess as to the stub's signature and change it when you guess wrong. I prefer not to guess, but rather to let the test tell me. There isn't much difference when a good IDE is there to support you. I suppose that the more you guess wrong, the more information that gives you -- perhaps you DON'T understand the task you're trying to implement. Back to the CRC cards... >> I don't use JUnitDoclet, so I can't comment on how using it changes the >> rules of the game. If it's easy to set up (less than 1 hour), then I >> may start using it, just for the experience. > >I'd be glad to help, if there would be a problem. >If you want to look at JUnitDoclet before you install it: > > http://www.junitdoclet.org/demo.html I'll check it out... >> I would like you to expand on this: what "documenting aspect" do you >> mean? and why does writing the stub first enable this feature and >> writing the test first not enable this feature? > >I hope, my lines in the beginning of this email clarified, >what I ment. Sorry, if I wasn't more precise in former emails. It did. Thanks. J. B. Rainsberger, President, Diaspar Software Services Let's write software that people understand. http://www.diasparsoftware.com/ telephone: +1 416 791-8603 All correspondence (c) 2002 Diaspar Software Services. If you want to use it, just ask; don't steal. To unsubscribe from this group, send an email to: junit-unsubscribe@xxxxxxxxxxxxxxx Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/