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 <false>
filter?
Cheers,
Chris
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 <false>
filter?
I built a patch that seemed to produce an intersection behavior, let me try to dig it up. Nathaniel Talbott was semi-interested in the idea.
···
On Jul 6, 2006, at 3:00 AM, Chris Roos wrote:
--
Eric Hodel - drbrain@segment7.net - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant
http://trackmap.robotcoop.com
> 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 <false>
> filter?
I built a patch that seemed to produce an intersection behavior, let
me try to dig it up. Nathaniel Talbott was semi-interested in the idea.
Hi Eric,
Did you find your patch at all?
Chris
···
On 7/6/06, Eric Hodel <drbrain@segment7.net> wrote:
On Jul 6, 2006, at 3:00 AM, Chris Roos wrote:
--
Eric Hodel - drbrain@segment7.net - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant
http://trackmap.robotcoop.com