a few feature and many fixtures

hi, i am writing a program that lets two players play a game of Go (game) - Wikipedia, the free encyclopedia http://en.wikipedia.org/wiki/Go_%28game%29 
 
 http://en.wikipedia.org/wiki/Go_%28game%29 
 
 Go (game) - Wikipedia, the free encyclopedia http://en.wikipedia.org/wiki/Go_%28game%29 Go (simplified Chinese: 围棋; traditional Chinese: 圍棋; pinyin: wéiqí, Japanese: 囲碁 igo,[nb 2] literal meaning: "encircling game", Korean: 바둑 baduk[nb 3]) is...
 
 
 
 View on en.wikipedia.org http://en.wikipedia.org/wiki/Go_%28game%29 
 Preview by Yahoo 
 
 
  
 on unusual go boards. some of the boards may have unusual shapes or have holes or have a strange topology (cylinder, torus). these boards will have some unusual features (not quite sure if i am using the work feature http://xunitpatterns.com/feature.html correctly here).

but my real problem is that i have a lot of test fixtures. these are boards of different sizes, shapes, holes and topology.

i have an abstract test case (atc) for the board interface, and concrete test case (subclass of atc) for the board implementation (impltc) and a couple feature test cases (subclasses of impltc) with not much in them now. 

the concrete test case creates a standard 19x19 board in setup (fixture) for some of the tests to use. but many of the tests create many boards. many of these boards are not changed, but some are (maybe i need an interface for an immutable board?).

in any case, many of the fixtures are being created many times. while not particularly slow, i feel that there may be a way to organize the test case class hierarchy for boards.

maybe a parameterised test case with a bunch of boards? or maybe one for normal boards and one for unusual 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.

any pointers will be appreciated.

thanks