[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Abstract Tests vs AutoRunner

Phlip

9/7/2006 12:49:00 AM

Rubies:

I'm trying to get some elaborate test suites working via the hidden call to
AutoRunner.

Because I can't declare which suites to run, the system tests anything that
derives from TestCase.

I want to do this:

class AbstractSuite < Test::Unit::TestCase
def test_foo()
p derive()
end
end

class ConcreteSuiteA < AbstractSuite
def derive()
return 'like this'
end
end

class ConcreteSuiteB < AbstractSuite
def derive()
return 'like that'
end
end

That's the skeleton of the Abstract Test pattern, which is a major Good
Thing. It prevents us from writing zillions of duplicate test cases with
minimal differences between each one. For example, my derive() could return
an object that must pass the same tests as another object, obeying Liskov
Substitution Principle.

However, I can't do it like that, because AutoRunner hoovers up every class
derived from TestCase, and runs all of them as suites. I predictably get
"test_foo(AbstractSuite): NoMethodError: undefined method `derive'"

The ugly fix is this:

class ConcreteSuiteA < Test::Unit::TestCase
def test_foo()
p derive()
end

def derive()
return 'like this'
end
end

class ConcreteSuiteB < ConcreteSuiteA
def derive()
return 'like that'
end
end

That works, but it's "not OO". ConcreteSuiteB is not truly a derived version
of ConcreteSuiteA.

So I'm asking this question because I don't understand mixins, or
AutoRunner, enough to fix this.

Could a mixin grant test cases to two concrete classes? Alternately, does
AutoRunner have a feature to bump a suite from its list?

--
Phlip
http://c2.com/cgi/wik... <-- NOT a blog!!!


3 Answers

chrisjroos@gmail.com

9/7/2006 7:10:00 AM

0

Indirectly answering your question, you could just define an empty
derive method in your AbstractSuite.

class AbstractSuite < Test::Unit::TestCase
def test_foo()
p derive()
end
def derive; end
end

Everything else remains the same, although the output from auto runner
will be a bit screwy (3 tests in this case, rather than the expected
2).

Chris

On 9/7/06, Phlip <phlipcpp@yahoo.com> wrote:
> Rubies:
>
> I'm trying to get some elaborate test suites working via the hidden call to
> AutoRunner.
>
> Because I can't declare which suites to run, the system tests anything that
> derives from TestCase.
>
> I want to do this:
>
> class AbstractSuite < Test::Unit::TestCase
> def test_foo()
> p derive()
> end
> end
>
> class ConcreteSuiteA < AbstractSuite
> def derive()
> return 'like this'
> end
> end
>
> class ConcreteSuiteB < AbstractSuite
> def derive()
> return 'like that'
> end
> end
>
> That's the skeleton of the Abstract Test pattern, which is a major Good
> Thing. It prevents us from writing zillions of duplicate test cases with
> minimal differences between each one. For example, my derive() could return
> an object that must pass the same tests as another object, obeying Liskov
> Substitution Principle.
>
> However, I can't do it like that, because AutoRunner hoovers up every class
> derived from TestCase, and runs all of them as suites. I predictably get
> "test_foo(AbstractSuite): NoMethodError: undefined method `derive'"
>
> The ugly fix is this:
>
> class ConcreteSuiteA < Test::Unit::TestCase
> def test_foo()
> p derive()
> end
>
> def derive()
> return 'like this'
> end
> end
>
> class ConcreteSuiteB < ConcreteSuiteA
> def derive()
> return 'like that'
> end
> end
>
> That works, but it's "not OO". ConcreteSuiteB is not truly a derived version
> of ConcreteSuiteA.
>
> So I'm asking this question because I don't understand mixins, or
> AutoRunner, enough to fix this.
>
> Could a mixin grant test cases to two concrete classes? Alternately, does
> AutoRunner have a feature to bump a suite from its list?
>
> --
> Phlip
> http://c2.com/cgi/wik... <-- NOT a blog!!!
>
>
>
>

Nathaniel Talbott

9/7/2006 12:36:00 PM

0

On 9/6/06, Phlip <phlipcpp@yahoo.com> wrote:

> Rubies:

I resemble that remark!


> Could a mixin grant test cases to two concrete classes?

require 'test/unit'

module AbstractSuite
def test_foo
p derive
end
end

class ConcreteSuiteA < Test::Unit::TestCase
include AbstractSuite
def derive
return 'like this'
end
end

class ConcreteSuiteB < Test::Unit::TestCase
include AbstractSuite
def derive
return 'like that'
end
end

Outputs:

Loaded suite t
Started
"like this"
."like that"
.
Finished in 0.000483 seconds.

2 tests, 0 assertions, 0 failures, 0 errors

Which I think is what you're looking for.

HTH,


--
Nathaniel Talbott

<:((><

Phlip

9/7/2006 4:18:00 PM

0

Chris Roos wrote:

> class AbstractSuite < Test::Unit::TestCase
> def test_foo()
> p derive()
> end
> def derive; end
> end

That would run test_foo() with a stub. Because the real derive() is
naturally important, this wouldn't work. It's also "not-OO", because it
isn't minimal!

I could do it like that if I were building the suites from scratch, and then
stubs would gracefully do nothing. But...

Nathaniel Talbott wrote:

> class ConcreteSuiteA < Test::Unit::TestCase
> include AbstractSuite

Jeeze Louise, could this friggin' language ever make anything HARD?! I need
to log hours doing SOMETHING!!!

--
Phlip
http://www.greencheese.u... <-- NOT a blog!!!