Re: Test::Unit maintainer

Kouhei Sutou wrote:

> Can I start to improve Test::Unit?

Per this thread's beginning, you should generally narrow Test::Unit by improving 
its capacity for customizations. To put a light refactor on that, I suspect you 
should break run(result) into into narrow calls that are easy to override:

       def run_case
         setup
         __send__(@method_name)
       end

       def run_fallible_case
         run_case
       rescue AssertionFailedError => e
         add_failure(e.message, e.backtrace)
       end

       def run_exceptional_case
         run_fallible_case
       rescue Exception
         raise if PASSTHROUGH_EXCEPTIONS.include? $!.class
         add_error($!)
       end

       def run_ensured_case
         run_exceptional_case
       ensure
         begin
           teardown
         rescue AssertionFailedError => e
           add_failure(e.message, e.backtrace)
         rescue Exception
           raise if PASSTHROUGH_EXCEPTIONS.include? $!.class
           add_error($!)
         end
       end

       def run(result)
         yield(STARTED, name)
         @_result = result
         run_ensured_case
         result.add_run
         yield(FINISHED, name)
       end

Esthetically, setup is no longer in the same method as teardown. The benefit is 
one could add a method like skip() by overriding only run_case, without then 
inflicting their change on all the other statements in there.

Also, most of the refactors required for that change were already in place. The 
system preferred methods over local variables, for example...

-- 
   Phlip