CODEWITHSUNDEEP
javagroovymocking
pfh
pfh

Reputation: 530

Groovy mocking File constructor, verify write on newly created files

Im trying to mock a new File generated in a loop. Simplified example:

class FileClass {

  def basePath
  def listObjects = []

  def createFilePerObject() {
    listObjects.each {currentObject ->
      File currentFile = new File("${basePath.toString()}/${currentObject.objectName}")

      currentFile.write currentObject.objectContent   //Verify this behaviour!!
    }
  }

}

class SimpleObject {
  String objectName
  String objectContent
}

And, the test:

class FileClassTest extends Specification {

  FileClass fileClass

  def "test simple object"() {

    def listObjects = []

    SimpleObject object1 = new SimpleObject(objectName: "First object", objectContent: "First object content")
    SimpleObject object2 = new SimpleObject(objectName: "Second object", objectContent: "Second object content")
    SimpleObject object3 = new SimpleObject(objectName: "Third object", objectContent: "Third object content")
    SimpleObject object4 = new SimpleObject(objectName: "Fourth object", objectContent: "Fourth object content")

    listObjects << object1
    listObjects << object2
    listObjects << object3
    listObjects << object4

    fileClass = new FileClass(listObjects: listObjects, basePath: ".")

    def dummyFile = new MockFor(File)
    def mockFile = new MockFor(File, true)  //Intercept constructor call

    mockFile.demand.with {
      File() {dummyFile}
    }

    when:
    mockFile.use {
      fileClass.createFilePerObject()
    }

    then:
    1 * mockFile.write(_)
  }

}

So, as you can see, im trying to verify that new files actually have something written in them.

And, i get the following error:

MockFor with constructor interception enabled is only allowed for Groovy objects but found: java.io.File

So, File is, as i understand, extended in groovy GDK(Groovy JDK), and it has additional(and very helpful) methods. But Groovy tries to mock java.io.File.

And, following the logic of the error, i decided to actually ovveride the File constructor like this:

class FileClassTest extends Specification {

  FileClass fileClass

  def "test simple object"() {

    def listObjects = []

    SimpleObject object1 = new SimpleObject(objectName: "First object", objectContent: "First object content")
    SimpleObject object2 = new SimpleObject(objectName: "Second object", objectContent: "Second object content")
    SimpleObject object3 = new SimpleObject(objectName: "Third object", objectContent: "Third object content")
    SimpleObject object4 = new SimpleObject(objectName: "Fourth object", objectContent: "Fourth object content")

    listObjects << object1
    listObjects << object2
    listObjects << object3
    listObjects << object4

    fileClass = new FileClass(basePath: ".", listObjects: listObjects)

    def mockFile = new MockFor(File)

    File.metaClass.constructor << {String filePath -> mockFile } //Return the mocked file, so it can be verified

    when:
    mockFile.use {
      fileClass.createFilePerObject()
    }

    then:
    1 * mockFile.write(_)
  }

}

And recived the warning that the constructor already exists(i guess i cant ovveride it after all):

groovy.lang.GroovyRuntimeException: Cannot add new constructor for arguments [[class java.lang.String]]. It already exists!

So, one of the ideas is to actually mock the File Factory that would produce the new File objects in the loop. However, the factory is, to say the least, useless - it would be used only to have the ability to test the file creation.

So, PowerMock doesnt work(cant load PowerMockRunner), any ideas how to mock this, not using additional libraries, and not end up with useless classes?

Thanks.

Upvotes: 3

Views: 2177

Answers (1)

Gareth Davis
Gareth Davis

Reputation: 28059

Can I suggest alternative non pure testing approach.

For this one test create a temporary directory, set basePath in your test subject and allow the test to actually write out the file. Your assertations will obviously have read the file in to verify the result, but it would be a complete test with out attempting to mock out JDK classes. The test teardown can then clean up the temp dir.

If you really are set on pure in memory unit testing, I'm afraid you might have to use JMockIt which if you can get your head around it and the documentation can mock just about anything including parts of the JDK.

Upvotes: 1

Related Questions