Mockito ignores my Specs2 sugared verify steps when traits are involved - scala

Normally Specs2 sugared Mockito verifications are checked and fails the test when appropriate. However in some instances they are ignored.
Normally this test verification fails as expected as myApp called myService at least once.
import org.specs2.mock.Mockito._
class MySpec extends Specification with Mockito {
"MyApp" should {
"blow up" in WithApplication {
val myService = mock[MyService]
val myApp = new MyApp(myService)
myApp.doSomething
there was no(myService).doSomethingElse
}
}
}
(Note WithApplication is a Play! Framework thing)
However as I have hamfisted Cake Pattern traits into my components my tests look like this.
class MySpec extends Specification with Mockito {
"MyApp" should {
"blow up" in WithApplication with MockRegistry {
val myApp = new MyApp(myService)
myApp.doSomething
there was no(myService).doSomethingElse
}
}
}
where MockRegistry looks something like this
trait MockRegistry extends Mockito with MyServiceComponent {
val myService = mock[MyService]
}
My Cake patterned test does not fail verification, ever. I can change this to anything and they all get ignored.
there was no(myService).doSomethingElse
there was one(myService).doSomethingElse
there was two(myService).doSomethingElse
However by replacing the sugared mockito step with a direct call to the java methods it does fail when appropriate.
import org.mockito.Mockito._
verify(myService, times(1)).doSomethingElse
So it seems involving traits on the test method seems to have properly confused Mockito.

That's because the Mockito extension of MockRegistry doesn't know that exceptions needs to be thrown in case of failure. But the Mockito on Specification does because Specification has the ThrownExpectations trait mixed-in.
So you can either removed the Mockito extension from MockRegistry or add ThrownExpectations to it:
trait MockRegistry extends MyServiceComponent {
val myService = mock(classOf[MyService])
}
// or
import org.specs2.matcher.ThrownExpectations
trait MockRegistry extends MyServiceComponent with ThrownExpectations {
val myService = mock(classOf[MyService])
}

And as expected it was due to the traits. It was in face due too many Mockito trait-ing...
My spec had a mockito trait. My cake pattern mocked component registry also had a mockito trait. On the test method they were both part of the object, which seems to confuse Specs2/Mockito.
So by removing Mockito sugar from my mock component registry:
//import org.specs2.mock.Mockito._
import org.mockito.Mockito._
trait MockRegistry extends MyServiceComponent {
val myService = mock(classOf[MyService])
}
And only have the Mockito sugar in the Spec then my sugared verifications started to work as expected again.

Related

Play Slick: How to inject DbConfigProvider in tests

I am using Play 2.5.10, Play-slick 2.0.2, and my activator-generated project comes with scalatest and code like this:
class TestSpec extends PlaySpec with OneAppPerSuite {...}
I managed to test routes/Actions; now I would test DAO methods on a lower level. I searched the web and SO for a solution, and could not find any that is still up-to-date. A DAO signature is like this:
class TestDAO #Inject()(protected val dbConfigProvider: DatabaseConfigProvider) extends HasDatabaseConfigProvider[JdbcProfile]
so I need to pass it the dbConfigProvider thing.
For some reason I can't inject the provider into the tests like we do in controllers (no error, tests just won't run):
class TestSpec #Inject()(dbConfigProvider: DatabaseConfigProvider) extends PlaySpec with OneAppPerSuite {...}
The Play-Slick docs say we can alternatively use a global lookup
val dbConfig = DatabaseConfigProvider.get[JdbcProfile](Play.current)
but it won't work directly because
There is no started application
and link to an example project doing that:
class TestDAOSpec extends Specification {
"TestDAO" should {
"work as expected" in new WithApplicationLoader { // implicit 'app'
val app2dao = Application.instanceCache[TestDAO].apply(app)
but I could never find the WithApplicationLoader. Instead, there seems to be a WithApplication:
class TestDAOSpec extends Specification {
"TestDAO" should {
"work as expected" in new WithApplication() { // implicit 'app'
val app2dao = Application.instanceCache[TestDAO].apply(app)
but then I get
Type mismatch: expected a play.api.Application, got: play.Application.
At this point I lost hope.
How can I test a DAO?
N.B. I don't need to switch databases for testing (I handle this via config), I just want to access the default database in tests.
You can use:
lazy val appBuilder: GuiceApplicationBuilder = new GuiceApplicationBuilder().in(Mode.Test)
lazy val injector: Injector = appBuilder.injector()
lazy val dbConfProvider: DatabaseConfigProvider = injector.instanceOf[DatabaseConfigProvider]

(Play 2.4) Dependency injection in a trait?

In play 2.4, is it possible to use dependency injection in a trait ?
Is there any example ?
Thanks.
I talk about runtime DI with Guice here because it's the default method used by Play. Other DI methods or frameworks may differ here.
It isn't possible to inject a dependency into a trait because a trait isn't instantiable. A trait doesn't have a constructor to define the dependencies.
In Play you could use the injector directly as long as the Application trait is in scope. But this isn't considered good practice in production code. In test code this would be an option.
class MySpec extends PlaySpecification {
"My test" should {
"Use the injector" in new WithApplication extends Context {
val messages = Messages(Lang("en-US"), messagesApi)
}
}
trait Context extends Scope {
self: WithApplication =>
val messagesApi = app.injector.instanceOf[MessagesApi]
}
}

Scalamock: How to get "expects" for Proxy mocks?

I am using Scalamock with ScalaTest, and am trying to mock a Java interface. I currently have:
private val _iface = mock [MyInterface]
now I want to do
_iface expects `someMethod returning "foo" once
But the compiler does not find expects.
I imported org.scalatest._ and org.scalamock.scalatest._. What else am I missing?
First of all, proxy mocks are not supported very well in ScalaMock 3, and I think they will be completely removed in ScalaMock 4. Do you really need to use proxy mocks instead macro mocks?
This should work:
package example
import org.scalatest.FlatSpec
import org.scalatest.Matchers
import org.scalamock.scalatest.proxy.MockFactory
trait MyInterface {
def someMethod : String
}
class MyTest extends FlatSpec with Matchers with MockFactory {
"MyInterface" should "work" in {
val m = mock[MyInterface]
m.expects('someMethod)().returning("foo")
m.someMethod shouldBe "foo"
}
}
If not, please check ScalaMock proxy mocks unit tests for more examples.
I think it should be something more like:
import org.scalamock.scalatest.MockFactory
class MyTest extends FlatSpec with Matchers with MockFactory {
"MyInterface" should "work" in {
val m = mock[MyInterface]
(m.someMethod _).expects().returning("foo")
m.someMethod shouldBe "foo"
}
}
I think the expects arg is expecting the arg to the function
I use scalaMock version 4.1.0, this works for me:
For some trait:
trait MyInterface { def someMethod(n1: Int, n2: Int) }
This should be put into a test
val myInterfaceMock = mock[MyInterface]
myInterfaceMock.someMethod _ expects (1,2)
For more reading: scalaMock Guide, you'll find some examples there

Why is this specs2 test using Mockito passing?

Suppose I had this interface and class:
abstract class SomeInterface{
def doSomething : Unit
}
class ClassBeingTested(interface : SomeInterface){
def doSomethingWithInterface : Unit = {
Unit
}
}
Note that the doSomethingWithInterface method does not actually do anything with the interface.
I create a test for it like this:
import org.specs2.mutable._
import org.specs2.mock._
import org.mockito.Matchers
import org.specs2.specification.Scope
trait TestEnvironment extends Scope with Mockito{
val interface = mock[SomeInterface]
val test = new ClassBeingTested(interface)
}
class ClassBeingTestedSpec extends Specification{
"The ClassBeingTested" should {
"#doSomethingWithInterface" in {
"calls the doSomething method of the given interface" in new TestEnvironment {
test.doSomethingWithInterface
there was one(interface).doSomething
}
}
}
}
This test passes. Why? Am I setting it up wrong?
When I get rid of the scope:
class ClassBeingTestedSpec extends Specification with Mockito{
"The ClassBeingTested" should {
"#doSomethingWithInterface" in {
"calls the doSomething method of the given interface" in {
val interface = mock[SomeInterface]
val test = new ClassBeingTested(interface)
test.doSomethingWithInterface
there was one(interface).doSomething
}
}
}
}
The test fails as expected:
[info] x calls the doSomething method of the given interface
[error] The mock was not called as expected:
[error] Wanted but not invoked:
[error] someInterface.doSomething();
What is the difference between these two tests? Why does the first one pass when it should fail? Is this not an intended use of Scopes?
When you mix-in the Mockito trait to another trait you can create expectations like there was one(interface).doSomething. If such an expression fails it only returns a Result, it doesn't throw an Exception. It then gets lost in a Scope because it is just a "pure" value inside the body of a trait.
However if you mix-in the Mockito trait to a mutable.Specification then an exception will be thrown on a failure. This is because the mutable.Specification class specifies that there should be ThrownExpectations by mixing in that trait.
So if you want to create a trait extending both Scope you can either:
create the trait from inside the specification and not have it extend Mockito:
class MySpec extends mutable.Specification with Mockito {
trait TestEnvironment extends Scope {
val interface = mock[SomeInterface]
val test = new ClassBeingTested(interface)
}
...
}
create trait and specification as you do, but mix-in org.specs2.execute.ThrownExpectations
trait TestEnvironment extends Scope with Mockito with ThrownExpectations {
val interface = mock[SomeInterface]
val test = new ClassBeingTested(interface)
}
class MySpec extends mutable.Specification with Mockito {
...
}

Using Akka TestKit with Specs2

I'm trying to craft a specs2 test using Akka's TestKit. I'm stuck on a persistent compile error I can't figure out how to resolve, and I'd appreciate suggestions.
The compile error is:
TaskSpec.scala:40: parents of traits may not have parameters
[error] with akka.testkit.TestKit( ActorSystem( "testsystem", ConfigFactory.parseString( TaskSpec.config ) ) )
Following suggestions from Akka docs and internet xebia and Akka in Action, I'm trying to incorporate the TestKit into a specs2 Scope. Here's a snippet of the code where I'm getting the error:
class TaskSpec
extends Specification
with AsyncTest
with NoTimeConversions {
sequential
trait scope
extends Scope
with TestKit( ActorSystem( "testsystem", ConfigFactory.parseString( TaskSpec.config ) ) )
with AkkaTestSupport {
...
I have the following helper:
trait AkkaTestSupport extends After { outer: TestKit =>
override protected def after: Unit = {
system.shutdown()
super.after
}
}
Here is one thing you can do:
import org.specs2.mutable.SpecificationLike
import org.specs2.specification._
class TestSpec extends Actors { isolated
"test1" >> ok
"test2" >> ok
}
abstract class Actors extends
TestKit(ActorSystem("testsystem", ConfigFactory.parseString(TaskSpec.config)))
with SpecificationLike with AfterExample {
override def map(fs: =>Fragments) = super.map(fs) ^ step(system.shutdown, global = true)
def after = system.shutdown
}
This should avoid the compilation error you had because TestKit is an abstract class and it is only mixing-in traits: SpecificationLike is a trait (Specification isn't) and AfterExample is a trait.
Also the specification above runs in the isolated mode, meaning that there is a brand new TestSpec object instantiated for each example and the AfterExample trait makes sure that the system is shutdown after each example.
Finally the map method is overriden with a special step to make sure that the system created for the first TestSpec instance (the one declaring all the examples) will be cleanly disposed of.