| «« Abstractulate Yourself | A Server for Every Occasion »» |
|
About
I'm Ryan Lowe, a Software Engineering graduate living in Ottawa, Canada. I like agile software development and Ruby on Rails.
I write this blog in Canadian English and don't use a spell checker. Typos happen.
Projects
» Full-time Ruby on Rails freelancer
» Full-time with Rails since May 2005 » Former committer for RadRails (now Aptana) » I also have a few Rails side-projects in development: 1. wheretogoinTO.com Toronto nightlife 2. Hey Heads Up! TODO list and sharing 3. Layered Genealogy family history research 4. foos for foosball scoring 5. fanconcert for music fans (on hold) Hiring Rails developers? I can telecommute by the hour from Ottawa, Canada »» Email: rails AT ryanlowe DOT ca
BulletBlog
Now hosted on Hey! Heads Up -- check it out!
Syndication
Pings
Recent
Derek Lowe's (Ryan's older brother) words at Ryan's funeral
blog@ryanlowe.ca no more Forging Email Headers: Good, Bad or Ugly? Sarcastic Dictionary (Part 1 of Many) Tags Hierarchies Twisting Rails is Risky Business Risky Business? My Take on Early Alphas Whoa, it's August 2007 Closing Comments A Postscript to "Growth at the grassroots" »» All Blog Posts
Linkage
del.icio.us/ryanlowe
technorati/ryanlowe.ca/blog Aurora Roy Jim Andrew Trasker Travis Kibbee Karen Dr. Unk Ayana Van Bloggers Joel Spolsky Robert Scoble Tim Bray Dave Winer Raymond Chen James Robertson Ruby/Rails Bloggers rubyonrails.org weblog David Heinemeier Hansson Dave Thomas James Duncan Davidson Mike Clark Jamis Buck Signal vs. Noise Tobias Luetke Amy Hoy: (24)slash7 Jeremy Voorhis Eclipse Bloggers Planet Eclipse EclipseZone Luis de la Rosa Eclipse Foundation Kim Horne Billy Biggs Ian Skerrett Mike Milinkovich Bjorn Freeman-Benson Denis Roy
Archives
|
My xUnit Wishlist
Some things I'd like to see integrated into a RAD programming unit test framework (ie. JUnit) for doing XP: 1. Automatic unit tests. For example, if one or more (in) parameters passed to a function is null, what does the function do? This check should be automatic in unit testing and should not have to be written explicitly save for the result. If a test isn't written at all, the unit tester should complain. 2. Tests for specific defects. A defect is opened. To close it, you need to write a test that replicates the defect and make sure it fails with the current code. Then you change (refactor/repair) the program code until it passes. Now you have a regression test for this defect and if the test fails you know the defect is back. 3. Built-in code coverage analysis If you are truly doing test-driven development, at any given time all lines in the program code should be executed by all tests. If this is not true, develop tests to exercise these lines or, even better, get rid of the superfluous lines. 4. A user-interface library that supports verification. How can I be sure that the user interface is correct at any given time without manually verifying it? The UI library should be written so that any element in the UI can be programmatically checked for properties such as visibility, position, etc. To see how involved this task can be, check out Liar Views. 5. User-interface can be controlled programmatically Any defect replicated in the field must be able to be replicated programmatically for a unit test. Posted at November 16, 2002 at 12:26 AM ESTLast updated November 16, 2002 at 12:26 AM EST Comments
For #1, before I even think about doing any code or how to approach the problem, I write out by hand all of the trivial cases, like NULL, or the Minima or Extrema input. You wouln't believe how often the simplest of the simple is skipped in the beginning. That should be where you start, using a pencil and paper, or whatever you use to write :-) » Posted by: roy at November 16, 2002 03:17 PMActually in test first development, these would be the unit tests you write first even before any program code. Don't bother writing the test cases down -- paper is a relatively useless software artifact. » Posted by: Ryan at November 16, 2002 05:45 PMDamn....I use that useless software artifact all the time though!! I must be a Dinosaur :-) » Posted by: roy at November 16, 2002 09:34 PMYeah, but how often do you use it after the first time? It's good to get ideas on paper at first, but throw it away. :) If it's on paper, chances are it'll be filed somewhere and forgotten about. Unit test cases can be run every day ... » Posted by: Ryan at November 16, 2002 09:46 PM |