On May 30, 2006, at 10:27 AM, Victor Shepelev wrote:
> From: Suraj N. Kurapati [mailto:skurapat / ucsc.edu]
> Sent: Tuesday, May 30, 2006 5:22 PM
>> Victor Shepelev wrote:
>>> 4. optional code speed analysis (like benchmarking "how long it  
>>> rans",
>>> profiling "what rans so long") after each test
>>
>> See the 'profile' library provided in Ruby core.
>>
>> ruby -r profile
>
> No-no :)
> I know, how to do it _technically_.
> What I what to know is how to _organize_ all the task.
> Just for now I do only unit-tests, but _when_ to run benchmarking /
> profiling / coverage analysis / dependency analysis and so on? Must  
> those
> tasks be ran automataically? When (after any code change, like unit  
> tests?)
> This is a question.

Personally, I don't think I'd want my tests run after *every*  
change.  But you might want to look into subversion's hook scripts.   
(post-commit, pre-commit, etc...).  The would allow the repository to  
run all the tests/profiling/coverage via rake and email the results  
to interested parties upon every commit.

BUT, I wouldn't focus too much on getting a lot of testing and  
profiling set up if you're just getting started.  Although ruby makes  
most of this stuff really easy, you'll still burn time and energy  
that might be better focused on the real task.  Don't optimize too  
early.
-Mat