Unit Testing, Test-Driven Development?

Jim

Just wondering if anyone could give a lesson on the who's, what's, where's, when's and why's of testing, and maybe write a how-to specifically for SketchUp/Ruby development.

Chris Fullmer

You mean to tell me there might be a better way than adding zillions of " puts "The script made it this far #1" " and UI.messagebox "Paused if its not broken!" lines of code throughout your scripts for debuging??

Jim

That's what I'd like to find out.

Dan Rathbun

Daniel J. Berger and Park Heesob, the guys who do the new Win32::apisuite[*], have a 'techique' of doing testing, using a Test module(s).

If you download some of their code packages, have a look specifically at the 'test' folders, and scripts. Should be informative. These guys work on the Ruby Core also I believe, so they know their stuff. Daniel at least is also a developer/administrator on RubyGems, Rdoc and Ruby/DBI.
Their RubyForge page: http://rubyforge.org/projects/win32utils/

[*] Win32::API is a newer replacement for the OLD 1.6.x Win32API.so and has many improvements, supports callbacks, etc.

Jim

Thanks Dan. I don't see anything special about it - it is using the unit test suite that comes with the installed Ruby language files.

I'm interested in a more fundamental conversation to answer the question of how testing might be used to make writing and debugging SketchUp/Ruby code more efficient; if it might be a good idea to incorporate the unit test suite files from the Ruby language install into the SketchUp/Ruby environment, or perhaps if a small library should be written specifically for SketchUp/Ruby?

My initial thought is that a few assert statements would go a long way to finding errors quickly, but in a way that amounts to adding type-checking to Ruby values - not a bad idea really, but how to incorporate it into the development cycle without imposing a performance penalty in the release version?

Finally, I'd like to know if I'm asking the right questions?

Dan Rathbun

@jim said:

... into the SketchUp/Ruby environment, ...

Could we use acronym 'SURE' (SkethcUp Ruby Embedded,) to refer to how Ruby is set up to operate under Sketchup, in contrast to how Ruby operates under the Standard Installation?* This is different from the SUAPI, which is how Sketchup simply extends the Ruby langauge (base classes) and adds it's application dependant Modules, Methods and Classes (which any script can do, even in the Standard Environment.)

@jim said:

... I'd like to know if I'm asking the right questions?
IMHO they appear to be vaild questions.

@jim said:

I'm interested in a more fundamental conversation to answer the question of how testing might be used to make writing and debugging SketchUp/Ruby code more efficient;
I am definately all for this!
I was playing around trying to get ALL errors to appear in MY error messagebox instead of the tiny postage-stamp sized one SU implements. It works only if I specifically call my ErrorBox method (from say a rescue clause, or a "if $DEBUG" statement.) But it doesn't work for the load method, even if I try to override it, because I think SU has already overridden it, (to accomodate the decrypting of .rbs files,) and aliased the original as "_load". So I still get the kwappy "Load Error" dialogs. Hmmm... I never did try to override _load, maybe that's the answer. I'll have to try it.

@jim said:

... if it might be a good idea to incorporate the unit test suite files from the Ruby language install into the SketchUp/Ruby environment, or perhaps if a small library should be written specifically for SketchUp/Ruby?
I haven't yet studied these standard libs.

Any tutorials online for using them?

@jim said:

My initial thought is that a few assert statements would go a long way to finding errors quickly, but in a way that amounts to adding type-checking to Ruby values - not a bad idea really, but how to incorporate it into the development cycle without imposing a performance penalty in the release version?

I definately don't want Ruby to be anything like Ada where even two strings of different lengths are considered different 'types'. (In Ada, you can't even compare or concatenate them without type converting one to the other's type.)
On the other hand, when types are too loose, it results in lazy and poor programming practices. (There are many examples of methods in the SUAPI that should have raised proper Exceptions when unsuccessful, but instead take advantage of Ruby's loose typing, and simply return nil. This technique is used for lazy conditional expressions because Ruby's NilClass is compatible with FalseClass in boolean expressions. This often results in the situation where we don't know why a method failed because there often are several failure modes.)

Dan Rathbun

@jim said:

... but how to incorporate it into the development cycle without imposing a performance penalty in the release version?

Definately, any Test or Debug module would be something we would ONLY load during testing.

We should not expect someone (ie the average user,) to have those modules loaded when they are just running and using Sketchup and the plugin (once it passes tests and is released.)

If you were testing a plugin on a model that was very big and had alot of textures, I'm sure performance would be reduced. That's only during testing tho.

Another option, is to cut up a Test or Debug module into smaller modulettes so only that which a tester needs is loaded. Perhaps take advantage of the autoload method, to do it automatically.