Re: a few feature and many fixtures

On 2/23/2015 9:43 AM, Ray Tayek wrote:
>
> hi, i am writing a program that lets two players play a game of go on 
> unusual go boards. ...
>
> ...
>
> i just ran across test case per fixture 
> <http://xunitpatterns.com/Testcase%20Class%20per%20Fixture.html> and 
> test case per feature 
> <http://xunitpatterns.com/Testcase%20Class%20per%20Feature.html> so i 
> am a little confused.
>

i rewrote the existing unit tests for the new stones, block and board. 
here's what i have so far:

topology - normal, horizontal cylinder, vertical cylinder, or torus
Stone - black, white, vacant, or edge. edge allows holes in the board.
Block - a contiguous group of stones (connected by the 4 points of the 
compass).
Board < BoardABC < BoardImpl (board class hierarchy)
BoardTestCase < BoardABCTestCase < BoardImplTestCase (board test case 
class hierarchy)

StoneTestCase tests 3
BlockTestCase  tests 13
BoardFactoryTestCase tests 3
BoardTestCase test 23 (abstract)
BoardABCTestCase tests 5 (abstract)
BoardImplTestCase tests 8 (concrete)
ParameterizedTestCase 1

most tests in the board test case hierarchy use the single board fixture 
generated by setup() in the concrete test case.

some (20%) tests roll up their own board(s) and test them.

one parameterized test case (not in the board test case hierarchy) will 
eventuall run many tests on many flavours of boards.

i only have tests for standard boards so far.

many tests are expected for unusual boards.

so it looks like maybe i should separate the tests into those that do 
create their own fixture and those that do not.

and parameterize the concrete board implementation test case with a 
bunch of boards for those tests that just use the given board fixture.

then move the tests that do roll up their own boards into a separate 
test case or hierarchy.

what do you guys think?

thanks

-- 
Honesty is a very expensive gift. So, don't expect it from cheap people - Warren Buffet
http://tayek.com/