Test/unit filters question/suggestion

When using the test/unit autorunner, you are able to supply some
options. Two of these options are -t (–testcase) and -n (–name); to
run only a given testcase or tests matching a given name respectively.
These two filters don’t get combined. If I have two test cases
containing a test of the same name, I’d expect to be able to specify
the exact test to run using both -t and -n. Currently -n appears to
take priority and therefore both test methods will be run. Is this
explicit by design or a result of my (potentially unusual) test
construction?

I just had a quick look at combining filters but my efforts were
hampered by the inclusion of a default filter that always evaluates to
false (set in AutoRunner#process_args). My solution was to be to run
through all filters (in Collector#include?) for a given method rather
than returning prematurely as in the current implementation. Does
anyone have any insight as to the purpose of the default
filter?

Cheers,

Chris

On Jul 6, 2006, at 3:00 AM, Chris R. wrote:

When using the test/unit autorunner, you are able to supply some
options. Two of these options are -t (–testcase) and -n (–name); to
run only a given testcase or tests matching a given name respectively.
These two filters don’t get combined. If I have two test cases
containing a test of the same name, I’d expect to be able to specify
the exact test to run using both -t and -n. Currently -n appears to
take priority and therefore both test methods will be run. Is this
explicit by design or a result of my (potentially unusual) test
construction?

I looked into this and found it filtered for the union of all options
rather than the intersection.

I just had a quick look at combining filters but my efforts were
hampered by the inclusion of a default filter that always evaluates to
false (set in AutoRunner#process_args). My solution was to be to run
through all filters (in Collector#include?) for a given method rather
than returning prematurely as in the current implementation. Does
anyone have any insight as to the purpose of the default
filter?

I built a patch that seemed to produce an intersection behavior, let
me try to dig it up. Nathaniel T. was semi-interested in the idea.


Eric H. - [email protected] - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com

On 7/6/06, Eric H. [email protected] wrote:

construction?
filter?

I built a patch that seemed to produce an intersection behavior, let
me try to dig it up. Nathaniel T. was semi-interested in the idea.

Hi Eric,

Did you find your patch at all?

Chris

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs