Approaches to testing that a method is not available on a type

Question

Given a type hierarchy for a game which strongly distinguishes whose turn is next:

trait Game
trait BlackToPlay extends Game {
  def move(p: BlackPiece, s: Square): Either[FinishedGame, WhiteToPlay]
}
trait WhiteToPlay extends Game {
  def move(p: WhitePiece, s: Square): Either[FinishedGame, BlackToPlay]
}

Can I make the following, important assertion without resorting to reflection?

"A game with white to play" should {
  "not allow black to play" in {
    // an instance of whiteToPlay should not 
    // have the `move(BlackPiece, Square)` method.
  }
}

EDIT: My attempt to implement @Martin's solution doesn't work. Any thoughts on what's wrong here? From the REPL:

scala> class B() {
     |   def b(s: String) = s
     | }
defined class B

scala> val b = new B()
b: B = B@420e44

scala> b.c("")
<console>:8: error: value c is not a member of B
       b.c("")
         ^

scala> b match {
     |   case _: { def c(s: String) } => false
     |   case _ => true
     | }
warning: there were unchecked warnings; re-run with -unchecked for details
res7: Boolean = false

res7 should have been true, because b should not match on the structural type of { def c(s: String) }

Read the warning, and re-run with `-unchecked`. You'll see a warning to the effect that structural types erase to `AnyRef`. Or, in other words, it is always accepted. — Daniel C. Sobral, Mar 12 '11 at 14:50
Or even type `:power` and then `settings.unchecked.value = true` to activate `-unchecked`. — Daniel C. Sobral, Mar 12 '11 at 15:05

Daniel C. Sobral · Answer 1 · 2011-03-12T15:27:10.000

5

You don't test what the type system already guarantees. In fact, the type system is already a test of certain properties of your program.

You could further on to test that the types you have guarantee a certain property (like no player making a move twice in a row), but this kind of thing is restricted to languages like Agda and Coq, for now.

edited Mar 12 '11 at 15:27

answered Mar 12 '11 at 14:52

Daniel C. Sobral

295,120
86
501
681

Thank you Daniel. Yes, I have often argued that the type system provides the cheapest 'unit tests' we can ever have. However, test cases are (in part) used as a protection against regression. The type system does not assert that a method is not present. I would like a test to ensure a method from a peer type in the hierarchy is never promoted upwards. E.G., if BlackToPlay.move was promoted to the Game type, then WhiteToPlay would be broken. It seems this can't be done. – Synesso Mar 13 '11 at 01:54

score 3 · Answer 2 · answered Mar 12 '11 at 06:43

3

Assuming BlackPiece is not a subtype of WhitePiece:

WhiteToPlayInstance.move(BlackPiece, s) should not compile - which means you can't write a test for it. The type system ensures that you can't move a BlackPiece on a WhiteToPlay.

answered Mar 12 '11 at 06:43

ssanj

2,169
3
19
28

Martin Ring · Answer 3 · 2011-03-12T18:30:20.090

1

EDIT: As Thomas pointed out, the below answer is nonsense since structural types cannot be used in pattern matches in the JVM version of scala.

Under normal cicumstances this doesnt make much sense because scala is statically typed and things like that are taken care of by the compiler but if you do make massive use of reflection or structural typing in your code it might be a good test:

instance match {
  case x: { def move(p: BlackPiece, s: Square): Either[FinishedGame, WhiteToPlay] } => // error
  case _ => // no error
}

edited Mar 12 '11 at 18:30

answered Mar 12 '11 at 07:30

Martin Ring

5,404
24
47

I had the thought of using structural typing when I was washing the dishes. Glad you picked up on it. I disagree about your last statement thought. The structural typing check is safer than an instanceof check, as only it is fulfilling the desired assertion. – Synesso Mar 12 '11 at 09:33
@Synesso Well... given the above code i would say it is not safer. Because you dont need to test that. You can actually proove it with the assumption that the compiler behaves correct ;). But if you want to test the compiler, you can do so. Maybe if you have many traits that all have methods with the same name and signature then it would be easier to test with structural typing instead of checking for all the traits. – Martin Ring Mar 12 '11 at 10:29
The compiler checks that called methods exist, but not the inverse. What I want to do, as an academic exercise, is prevent regression errors resulting from the addition of an unwanted method on the type. – Synesso Mar 12 '11 at 10:46
@Synesso ok... dont know what you are doing in your code. I can now think of situations where it would make sense if you use reflection or structural types in your code so i edited my answer. – Martin Ring Mar 12 '11 at 11:08
My apologies Martin. It may be that what I'm trying to do is stupid. I'm not convinced either way yet. Thank you for your help! BTW, I am finding your solution is matching incorrectly. About to edit my question to demo that. – Synesso Mar 12 '11 at 11:14
@Synesso i forgot about the return type (see edit). Could that have been the problem? – Martin Ring Mar 12 '11 at 11:17
Sorry, but structural types cannot be used in pattern matching. Or, rather, they can, but it will be erased to `AnyRef`. – Daniel C. Sobral Mar 12 '11 at 14:51

score 1 · Answer 4 · answered Mar 13 '11 at 20:01

If you really want to test for such things, move the check from type checking to something dynamic. Assume that WhitePiece and BlackPiece share a common supertype Piece:

trait Game {
  def move(p : Piece, s : Square) : Either[FinishedGame, WhiteToPlay]
}

trait BlackToPlay extends Game
trait WhiteToPlay extends Game

Then a test could look like this:

val b2p : BlackToPlay = ...
val bp : BlackPiece = ...
val wp : WhitePiece = ...
{a move bp} must not produce [IllegalMoveException]
{a move wp} must produce [IllegalMoveException]

I am not sure this would be good design, but it makes your system explicitly testable.

score 1 · Answer 5 · answered Mar 15 '11 at 00:35

I know you didn't want a reflection solution, but you could (if scala 2.9 is acceptable) use the new Dynamic trait like this:

class ReflectionDynamic[T <: AnyRef](t: T) extends Dynamic {
  def typed[A]: A = sys.error("doh");

  def applyDynamic(name: String)(args: Any*) = {
    val argRefs = args.map {
      case a: AnyRef => a
      case _ => sys.error("only AnyRefs")
    }
    t.getClass.getMethod(name, argRefs.map(_.getClass): _*).invoke(t, argRefs: _*)
  }
}

... and that will give this positive test:

val dynamicWhiteToPlay = new ReflectionDynamic(whiteToPlay)
dynamicWhiteToPlay.move(new WhitePiece, new Square) must_== Right(blackToPlay)

... and this for negative:

dynamicWhiteToPlay.move(new BlackPiece, new Square) must throwA[NoSuchMethodException]

score 1 · Accepted Answer · answered Mar 28 '11 at 23:24

The question is akin to asking: Given val f: (Boolean) => Int, how can I test that f("hello world") is rejected by the compiler?

After some brief conversation at the Melbourne Scala User Group my question was validated (yay). After all, the restriction I'm trying to test for is included by design and therefore deserves a test.

Bernie Pope suggested that the mechanism required is Automated Theorem Proving. @daniel-c-sobral was kind enough to mention Agda and Coq in a slightly different context and indeed these are ATP technologies which could prove my application to be correct.

Another suggestion was to execute the offending code as a script and assert that it fails. A poor-mans eval, if you like.

Approaches to testing that a method is not available on a type

6 Answers6