ScalaMock 2.2

Published
by
paul
on January 8, 2012
in Uncategorized
. 7 Comments

I’ve just released ScalaMock 2.2, with the following improvements over 2.1:

  • Add support for repeated parameters (varargs)
  • Basic parameterised class support

ScalaMock is a native Scala mocking framework which, as well as traits (interfaces) and functions, can also mock:

  • Classes
  • Singleton and companion objects (static methods)
  • Object creation (constructor invocation)
  • Polymorphic (type parameterised) methods
  • Classes with private constructors
  • Final classes and classes with final methods
  • Operators (methods with symbolic names)
  • Overloaded methods

7 Responses to “ScalaMock 2.2”

Feed for this Entry Trackback Address
  1. 1 Paul
    January 8, 2012 at 9:55 pm

    Hi Paul,
    I am just trying your mocking library for the first time. I hit a couple of compile errors

    The generated mock methods for methods ending in ? and + don’t compile. The generated method name needs a space before the :

    For example the following is generated (and does not compile)

    def post_?: Boolean = …

    but this would work

    def post_? : Boolean = …

    The other problem is where the class extends a trait with a lazy val, which gives “method X needs to be a stable, immutable value”.

    Not sure what you can do about that one. Keep up the good work!

  2. 2 paul
    January 8, 2012 at 10:31 pm

    Thanks for the feedback, Paul.

    The issue with question-marks should be easy for me to fix.

    Embarrassingly, I haven’t tested lazy vals – I’ll investigate and see if I can work out what’s up.

    Can you do me a favour and create issues in GitHub for both of these? Thanks!

  3. 3 Emil
    February 2, 2012 at 2:47 pm

    Hi Paul!

    Like Paul I just started looking at ScalaMock and it looks nifty! I have however discovered an issue I think.

    When mocking an object like:
    object Foo {
    def foo(s:String)(t:String):List[String] = List(s,t)
    }

    The generated mock does not compile:
    object Foo extends Mock$$Foo {

    def foo(s: String): (t: String)List[String] = if (forwardTo$Mocks != null) forwarder$0(s) else mock$0(s)
    // other generated methods here
    }

    As you can see the generated mock does not implement the correct method signature. After the first parameter list it inserts “:” expecting a return type.

    Should I create an issue on GitHub for this?

  4. 4 paul
    February 2, 2012 at 6:24 pm

    Oops – thanks for letting me know. Shame on me for letting that slip through my testing!

    Yes, please do create a bug and I’ll get to it as soon as I can.

  5. 5 Ryan
    February 3, 2012 at 4:38 am

    Hey Paul,

    Any chance the “method needs to be a stable, immutable value” is resolved? I’m still getting the error. I’ve used the following in my SBT however:

    libraryDependencies += “org.scalamock” %% “scalamock-scalatest-support” % “latest.integration”,

    Thanks in advance,
    Ryan

  6. 6 Ryan
    February 3, 2012 at 5:16 am

    Hey Paul,

    Just a little extra information regarding the post above. I noticed the original comment about the immutable method error was associated with lazy vals. I seem to be getting this when using a trait that has vals (not necessarily declared as lazy either). The mock object tries to override the val as a def.

    Also, if you’d prefer me to post questions / issues in another forum, please let me know.

    Thanks,
    Ryan

  7. 7 paul
    February 3, 2012 at 5:38 pm

    Ryan,

    The best forum is probably the scalatest mailing list: http://groups.google.com/group/scalatest-users

    There’s an open ticket about the problem with vals here:
    https://github.com/paulbutcher/ScalaMock/issues/3

    As you can see from that bug, it turns out to be a more fundamental problem than it first appeared to be. I believe that I have worked out the structure of a solution, but I don’t have an implementation of it yet.

Leave a Reply