From: Phlip Date: 2001-12-03T13:20:47+09:00 Subject: [ruby-talk:27317] Re: Quantitative Unit-testing? A call to arms! Stefan Schmiedl wrote: > unit tests in isolation are as much evil as every other part > of a software building process in isolation. The Point is to write the tests in lockstep with writing the code. That's not "isolation". (And don't nobody _dare_ mention the word "isolation" to a hardcore eXtremo who works AllEngineersInOneRoom, OnsiteCustomer and two developers to each workstation!) > if someone does, you will receive a bug report. you can add > another test thus enhancing the interface or tell the other to > rtfm and leave things as they are. without feedback things won't > work. Feedback forms a dynamic attractor that targets good, clean, solid code. > you have functional/acceptance/user tests controlling the > behaviour on a larger scale. and why do you need to "prove" > something? the ultimate criterium of usefulness is whether > something works and if it does not, fails gracefully. there is a > well-known saying of don knuth regarding this matter. Try to test at any scale necessary. Every function should be short, and should have a longer function or seven testing it. Doing things like this lets you go as fast as you possibly can, because you know when everything works and you know exactly what broke when it broke. No stops to manually test to see if a refactor worked; you just know. Have I mentioned here recently that I did Flea in my spare time; less than an hour a day? http://flea.sourceforge.com >> 3. I believe (automated) unit tests are a good technique for >> discovering bugs due to changes made to the system, early on. >> But it is misleading to imply that since you have written and >> run *some* tests, your system now works "correctly". Yet this is >> what a consultant might tell a customer: "Look, we have all >> these unit tests in place, and we run them all without errors! >> We don't need interface contracts. We don't need specifications. >> Our code is simply the best since it passes all unit tests we >> have written!" Real consultants engage with a real customer in real time. This is a Tom Peters concept that I doubt anyone here's brave enough to cross him over. The developers do not keep them in the dark until the great unveiling. The customer sees the project grow in real-time, and steers it in real time. They see each bug that gets off the bench, and they see how short its life is. They know a project's risk profile. > this is the same consultant that sells you other methodologies > with other inherent flaws by promising other stuff that cannot be > guaranteed. it's a fault of the consultant, not of the unit test. Agreed. > unit tests help you immensely in diagnosing problems, both early > and late in development. they are no silver bullet. you still need > to apply whatever knowledge you have acquired. They are a bullet with a very high albedo. That's why they are taught to freshpersons in their first semester of programming classes. > but do you believe that you are completely healthy, only because a > doctor told you so? I'l play the odds here. Biological organisms weren't invented TestFirst. >> Wouldn't it intuitively make sense to have another set of people >> writing the tests, than the ones writing the code which must >> pass those tests? Yes, of course. It would make perfect sense to do things the way that great bastion of rock-solid code and thrifty processes, Microsoft, does things. -- Phlip http://www.greencheese.org/HatTrick