Section 5

Perhaps there's more going on here than just a bad unit test. We're failing at the test point 10@30 and instead of answering a rotation region of CellClickRegionRotateCounterClockwise, we're getting CellClickRegionRotateClockwise.

According to our previous design, when the pointer is in the outside region and in the upper half, we should go clockwise. In the lower half we go counter-clockwise. This test point is clearly in the lower half so something must be incorrect because the code is answering clockwise.

If you use the debugger on the failing test you eventually get to selection code that determines if the point under evaluation belongs to the clockwise or counterclockwise region. Here's the existing code on the CellClickRegionRotateClockwise class. This is the class method #containsPoint:.

containsPoint: aPoint
    ^aPoint y <= (CellRenderer cellExtent y)

Here's the same class method in the CellClickRegionRotateCounterClockwise class.

containsPoint: aPoint
    ^aPoint y > (CellRenderer cellExtent y)

How was this ever working correctly? There's no check for which half the test point is within. In the #rotateRegionForPoint class method on the CellClickRegionOutside class, this is how it made its decision.

rotateRegionForPoint: aPoint
    ^self subclasses detect: [:cls | cls containsPoint: aPoint]

We need to change the two #containsPoint: class methods. Here's the new one for the CellClickRegionRotateClockwise class.

containsPoint: aPoint
    ^aPoint y <= (CellRenderer cellExtent y // 2)

And the changed class method for the CellClickRegionRotateCounterClockwise class.

containsPoint: aPoint
    ^aPoint y > (CellRenderer cellExtent y // 2)

When we re-run the test now passes.

Index Page Next Page

Copyright © 2007, 2008, 2009, 2010 Stephan B Wessels    stevewessels@me.com