Saturday, January 24, 2004

David Whitney wrote: > I'd appreciate any and all feedback. If I'm the idiot, please say so. The subject is reuse of code between products. People in his group didn't see the need for reuse and didn't even like the idea of reuse. My Reply: You are not an idiot, but i don't think you are sufficiently cynical on serendipitous reuse. Making yourself dependent on code under a different policy domain adds risk. A risk similar to using any 3rd party code. Once bitten twice shy. The people working on that code base are probably not aware of your dependency, your requirements, your process, your expectactions, your release schedules, etc. A process that would work is to move shared code to its own library that is developed on its own and imported into each product as a 3rd party product. This sets a defined policy domain and everyone is aware of dependencies. If all the parties do not agree to this policy then it's a clue to you that sharing will be risky. Instead, create the code from scratch, or fork the code by copying it into your own environment. comment[] 12:28:54 PM     Time spent creating mock objects is often wasted. The "T" in Test Driven Design is just as important as the "D." Real tests--ones that find bugs--require testing real code. Emphasizing making fast tests using mocks misses what is most important: creating code that works in your deployed environment. If your code passed a unit test using mocks but failed in a system test, you would get no sympathy from me. Your shit must work, i don't want to hear about the rest. This may sound stupid, but things are what they are. If you have a rule like tests must be fast, and apply that rule blindly, then you are not paying attention to what things are, you are just paying attention to the rule. This causes you to justify dropping testing in favor of test speed. For the same reason people say you don't need to test setters and getters, i don't really find a lot of problems with incorrect communication with other classes. For all the pros of the design part of TDD, i still want to find bugs and to find the "real" bugs you need to test the real code. If that takes time then it takes time. Favoring mock creation means i am spending considerable time creating tests that skip about a gazillion failure interaction modes. That's time i would rather spend on finding real problems in real code and creating real code to solve real problems. You want to find problems in unit tests rather then system or acceptance tests because bugs are much easier to find, reproduce, and fix in the unit test environment. If it is being said problems will be found at higher levels of test then i think you can do away with most unit testing period because you can always make this argument. I do use mocks, have for many many years, but using mocks is a last resort for me, not the way to do everything. The above response is in reaction to: > Seth Ladd: >I think the goal of writing a good unit test harness is that running all the tests should be extremely quick. >If your tests require database connections, consider using Mock Objects. Or break out your data access > into interfaces and create a very light weight file based data store. You're solved two issues here: > your tests run w/out a database, and your code is a bit more flexible and testable. > The more and more I write my tests using Mock Objects, the quicker my tests become. Also, it minimizes the > need for external resources which makes setup easier. > Tests can take a long time, but through careful creation, can execute quickly. > Michael Feathers: >When you use mocks you are testing real code. >You are testing whether it communicates correctly >with another class comment[] 10:25:40 AM

© Copyright 2004 todd hoff. Last update: 1/24/04; 12:38:56 PM.