Re: a few feature and many fixtures

For what it's worth, I've often found that it's easy to optimize test
hierarchies too quickly.  I'll often focus first on factoring common code
so that my test cases can be succinct:

@Test public void testNormalBoardHas4Corners() {
  assertEquals(4, NORMAL_BOARD.numCorners());
}

@Test public void testMoebiusBoardHas0Corners() {
  assertEquals(0, MOEBIUS_BOARD.numCorners());
}

The one thing that can be annoying in these cases is keeping the test names
interesting and accurate.  But I find that it's much easier to come back to
tests written in this way 6 months later and remember what they're doing
than it is when using a more complicated hierarchy or parameters-based
approach.

Your mileage, of course, may vary.  Good luck!

   David Saff


On Sat, Feb 21, 2015 at 10:17 PM, [email protected] [junit] <
[email protected]> wrote:

>
>
> 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>
>        [image: image] <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
>
>
>  
>