|
in reply to Re: Testing for Beginners
in thread Testing for Beginners
Use caution especially around XP advocates, who are known for writing tests such as "verify 1 + 1 = 2".
While I confess that there are many XP advocates who get down to that level of detail, what you should hear from them is "don't test what can't fail". I would never test that chomp is doing its job, for example. However, the flip side of that is important. When something that can't fail does, then you write the test.
|
Re: Re: Re: Testing for Beginners
by flyingmoose (Priest) on Apr 08, 2004 at 19:53 UTC
|
If you want to buy into six degrees of seperation, the XP-type people I have known, met, or heard and had problems with either their thoughts or their examples include:
A professor/consultant, who was good friends with Kent Beck and involved in the books (SEP: 1) -- he advocated code should average 2.5 lines per method, which is utter hogwash and results in just a different kind of maintaince problem -- which I have oft referred to as politically correct obfuscation. He essentially took the obfuscation inherit in Java's OO model when overblown, and overblew it further.
Another professor, who was a follower of that guy above (SEP: 2)
Various other professors who were fairly hardcore on the subject (SEP: 3) and also advocated similarly lame XP testing practices
Martin Fowler (SEP: 0) (but only on the controversially lame "refactoring" subject, which mostly stated the obvious)
Anyhow, beware the academics who do not practice! And beware the overpaid consultants as well! "Best practices" is always a phrase that must be evaluated carefully and with a rationale mind. Keep asking "well, it sounds good, but does it really work...and why?"
Don't get me wrong, testing can work...but is part of a whole, and I definitely don't buy into XP-based test-driven development, pair programming, puny methods, no design up front, or ... well ... any of it. That being said, I *AM* a advocate for pristine clean code, quality software, and good testing. I'm not slacking here, I'm saying don't buy into the hype, XP doesn't solve as many problems as they claim. And it clearly isn't for everyone.
| [reply] |
|
|
I definitely am curious about some of this. What's wrong with test-driven development? After doing this for over a year, I've found out that my methods are more sane, my design is more intelligent, I turn out code faster and my software is much more robust. I am a much better programmer for it.
As for pair programming, it's controversial, but I have a lot of first-hand experience with it. At my work we have some people who were deadset against pair programming, yet have admitted that it works. Programmers who don't pair often struggle with parts of the system they don't understand. They are more likely to make design mistakes that happen by simply choosing the first implementation that occurs to them. In the past couple of months, we've fallen away from pair programming and we've seen our bug rate go back up, so we're moving back to pairs. On the other hand, while it may cost more money to program in pairs, it will cost us much more money if our bugs lose us clients.
No design up front is frequently misunderstood. This philosophy does not mean no thought up front. There's nothing wrong with realizing building a CAD system with ray-tracing shouldn't be using Perl to handle the math. Instead, by delaying the design on sections until you need them, you find that the design emerges from the refactoring. On my direct project, I work with a team that has a code-base of a quarter million lines of code (not counting the Mason side), yet the design has truly emerged without designing things. This is due to the refactoring that must be done. Many XP practices are tightly coupled to other practices. If you don't implement one, others can suffer. In the case of refactoring, failure to do that forces BDUP (Big Design Up Front), but since you should be refactoring anyway, why not allow the design to emerge naturally?
Another critical issue with "no design up front" is "choosing a metaphor". Many programmers laugh and skip this step, but it's very important. Imagine that your metaphor for a file shuttle program involves a train picking up passengers at a station and dropping them at various stations along the way. When someone wants the system to read a data file, you can think of that as picking up a passenger. When they suggest that the software play MP3s, you might reasonably ask how that fits the metaphor. If it doesn't, either the metaphor is bad and you should choose a new one or the feature request doesn't fit what the system is trying to do. This can help prevent scope creep when your pointy-haired boss suggests Clippy for your file shuttle program. As a result, a properly chosen metaphor helps to maintain consistency -- a critical aspect of design.
Certainly there are projects for which XP is not appropriate. I wouldn't want NASA programmers to use XP. I wouldn't expect a team of 30 developers to use XP (then again, I would also expect a higher project failure rate with a team of 30 developers -- see The Mythical Man Month). What XP really gives us is not refactoring. It's not "test first". What XP does is put into place a system whereby everyone knows everyone else's responsibilities and everyone has the information they need to do their job. Any good project management system addresses that need first. The rest is just gravy.
XP is not required to turn out good software. What is required is easy access to information at every stage of the game and, as any (competent) project manager will tell you, information management is not an easy task. If you decide not to go with XP, you still have to manage that information. Without some formal model to manage it, you have to create one yourself. Rare the is manager who can truly create that from scratch. XP, while not turnkey, is pretty darned close, once people understand how it helps them.
| [reply] |
|
|
