Beauty Is in the Eye of the Beholder
Alex Papadimoulis discusses ugly code, where it comes from, how to avoid it, and how to get rid of it.
Presentation
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Recorded at:
Testing is Overrated
Presented by
Luke Francl
on
Jan 02, 2009
Length 00:22:25
How would you like to view the presentation?
In case you are having issues watching this video, please follow these simple steps to help us investigate the issue:
1. Right click on the video player and select Copy log
2. Paste the copied information in an email to video-issue@infoq.com (clicking this link will fill in the default details in most email clients).
Note: in case your email client hasn't automatically picked up the email subject, please include in your email the URL of the video too.
3. Done.
We will investigate the issue and get back to you as soon as possible. Thanks for helping us improve our site!
1. Right click on the video player and select Copy log
2. Paste the copied information in an email to video-issue@infoq.com (clicking this link will fill in the default details in most email clients).
Note: in case your email client hasn't automatically picked up the email subject, please include in your email the URL of the video too.
3. Done.
We will investigate the issue and get back to you as soon as possible. Thanks for helping us improve our site!
Summary
Developer-driven testing is probably the most influential software development technique of the last 10-15 years. There's no question that it has improved the practice of building software. And in a dynamic language like Ruby, it's hard to get by without it. But is it really the best way to find defects? Or is the emphasis on testing and test coverage barking up the wrong tree?
Bio
Luke Francl is a developer at Slantwise Design (http://slantwisedesign.com) and sometimes tech writer. Luke is a frequent presenter at the Ruby Users of Minnesota, and has also presented at CodeCon, MinneBar, Ostrava on Rails, and acts_as_conference. He blogs at Rail Spikes (http://railspikes.com) and Just Looking (http://justlooking.recursion.org).
About the conference
RubyFringe is an avant-garde conference for developers that are excited about emerging Ruby projects and technologies. They're mounting a unique and eccentric gathering of the people and projects that are driving things forward in our community.
Developer-driven testing is probably the most influential software development technique of the last 10-15 years. There's no question that it has improved the practice of building software. And in a dynamic language like Ruby, it's hard to get by without it. But is it really the best way to find defects? Or is the emphasis on testing and test coverage barking up the wrong tree?
Bio
Luke Francl is a developer at Slantwise Design (http://slantwisedesign.com) and sometimes tech writer. Luke is a frequent presenter at the Ruby Users of Minnesota, and has also presented at CodeCon, MinneBar, Ostrava on Rails, and acts_as_conference. He blogs at Rail Spikes (http://railspikes.com) and Just Looking (http://justlooking.recursion.org).
About the conference
RubyFringe is an avant-garde conference for developers that are excited about emerging Ruby projects and technologies. They're mounting a unique and eccentric gathering of the people and projects that are driving things forward in our community.
RelatedVendorContent
Transforming Software Delivery: An IBM Rational Case Study
Five Key Practices to Agile ALM
Related Sponsor
In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!
- This article is part of a featured topic series on Agile
- See more Agile content at: http://www.infoq.com/agile
- Other recent content items in this topic
Missed the point
by
Channing Walton
Posted
Re: Missed the point
by
Clinton Begin
Posted
Re: Missed the point
by
Franz Allan See
Posted
Re: Missed the point
by
Markus Kohler
Posted
Interesting
by
Prajwal Tuladhar
Posted
Progress?
by
Christoph Henrici
Posted
testing is just a substitute
by
Eirik Maus
Posted
Value of testing
by
Tony Ambrozie
Posted
-
TDD is not just about testing, it’s a design technique.
-
Interesting presentation and good sense of humor while presenting
-
Agreed.
-
It is really astonishing where the scripting languages are getting too and selling it progress....
-
(Unit) Testing is not about getting all bugs at once. It's about getting (and fixing) bugs fast (even if you don't do TDD).
When you write a code with test, other developers can go in and change it and see if they broke anything functionality that you did.
And if during the course of usage, a bug arises, you can debug your code easier if you have tests all around. Because those states who are not tested are most likely be the suspect (thereby decreasing the states that you have to go through).
Having unit tests will not guarantee a bug-free system. But it should speed things up in fixing them. -
... for real-world feedback. It is a substitute that is repeatable and instantaneous and with no damage done.
Exposure to the real world is actually better, since it better (very effective, actually) to find errors in the specifications. However, making errors in the real world, when you are developing money-moving software with more than 10 digits for the amount, is not so practical. -
Agreed.
Without good unit testing, refactorings are suicide. -
I will take this (humorous but well argued) presentation as really a re-affirmation of the valuable but within-limits benefits of unit testing. As with any good thing, we have to be careful to clearly set expectations of its limitations: I agree that metrics get sometimes out of hand and become meaningless, I also agree that you can't test what wasn't implemented and should have and that unit code testing does not replace end-user testing.
With that said, code testing does improve quality of implemented code and features (in my own experience), it provides a firm base to validate the aging code (as during refactoring) and new features against and, not lastly, provides a form of code documentation (most importantly the intention behind the code -- not just mere comments in code -- which will be valuable years later, as some code runs and it is maintained by many people for long periods of time.) I would not discard here the sense of confidence good tests passed inspire in developers, especially important during difficult project periods. I would also think that scripting/dynamic languages need more testing because of the absent/reduced compiler-supported validation. The problem with insufficient negative case testing -- testing for what could go wrong -- comes from the fact that, in reality, too little attention is given to that -- starting with requirements, use cases, etc -- at a project/product technical and management level, and that is something we can do something about.
I have not seen code reviews ensure quality of code in a sustainable manner, either as a code reviewer or reviewee -- unless if that is part of pair-programming -- but that could be subjective.
To conclude, I believe we should be doing (more) testing but understand and act upon its limitations and benefits vs. costs for each particular situation.
8 comments
Watch Thread Reply