Re: a few feature and many fixtures

On 2/23/2015 1:03 PM, David Saff [email protected] [junit] wrote:
> 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());
> }
yes. i agree. will do.
> 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.
yes, that is one big advantage.

thanks
>
>
> On Sat, Feb 21, 2015 at 10:17 PM, [email protected] 
> <mailto:[email protected]> [junit] <[email protected] 
> <mailto:[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 <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
>
>
>
> 

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