Philipp M

Could you try to create an adaptor between your code and the native class? E.g. like this: ``` // stub to define the functions you intend to use from the...

@sjrd or @gzm0 - do you have a view on how to safely subclass things like `CanvasRenderingContext2D`?

`mock[T]` creates an anonymous subclass of `T`, which is why the mechanisms around js.native are a bit problematic. From a mock perspective the ideal is a plain trait without implementations,...

Thanks, makes sense not to introduce abstractions - just wanted to be sure there isn't an easy way out before investing a lot of time.. What that means is that...

good to know, but still need to check parameters for the defaults (which need repeating)?

added a test case at https://github.com/paulbutcher/ScalaMock/blob/master/js/src/test/scala/org/scalamock/jstests/JSNativeTest.scala but wasn't able to develop a fix yet.

that is an interesting one. I experimented a bit myself: ``` test("varargs") { trait Foo { def foo(what: String*): String def bar(i: Int)(what: String*): String } val m = mock[Foo]...

If `def bar(i: Int)(what: Any*): String` is mocked with `(m.bar(_: Int)(_: Seq[_])) expects (42, Seq("1")) returning "baz" once()` everything works fine, but not with `String*` as a type

sorry, closed accidentally

Maybe this workaround is helpful in the meantime: ```Scala "Varargs in 2nd param list" should "be mockable" in { trait TypeToMock { def bar(i: Int)(what: String*): String } trait Workaround...