So… for the startup I work for, one of the many hats I wear is de-facto tester. Now, I have little EXP testing, so naturally, I’m starting at the bottom and working my way up the chain of knowledge. It’s a good way to learn how a project is built, and for someone like me who is trying to become a full-stack developer – but is more of a front-end guy – it seems you never get the back-end tasks, so this may be the closest you will get to working with the controllers, jobs, and Services.

To get you up to speed, we are running tests similar to JUnit, but for Groovy. The framework we are writing in is called Spock. A Spock test looks something like this:

import grails.test.mixin.TestFor
import spock.lang.Specification

@TestFor(User)
@Mock(User)
class UserSpec extends Specification {

    def path = "./grails-app/assets/images/testingStuff/"
    def photo = path + "oilers.png"
    def largePhoto = path + "large.jpg"
    @Shared file = new File(photo)
    @Shared hugeFile = new File(largePhoto)

    void "test accessors and mutators work"() {
	setup:
	user.setEmail("spock333@gmail.com")
	user.setPhoto(file.getBytes())
	mockForConstraintsTests(User, [user])

	expect:
	user.getEmail() != null && user.getEmail() == "spock333@gmail.com"
	user.getPhoto() != null && user.getPhoto() == file.getBytes()
    }
}

Now, we have a constraint in the User domain that states that a photo larger than 2MB will fail to validate. Fair enough. We don’t want people using 4000x5280px png’s.

Anyway, I read about the @Shared annotation in Groovy/Spock testing yesterday. What it does is it allows an expensive resource to be reused each test, saving a lot of overhead if your resources are expensive (Such as a 2MB+ photo). So, I started getting crafty, and made large resources in this test @Shared. Later, I read that after a test, you should be nice and destroy the resources in the cleanup: block. So, I added this code to the cleanup method without thinking about the consequences:

    void "test accessors and mutators work"() {
	setup:
	... ...

	expect:
	... ...

        cleanup:
        file.destroy()
    }

Now comes the interesting part – This test passed the first time I ran it. Then I made some small changes to some other stuff and ran the test again, but nothing that would cause it to fail. However, to my surprise, the tests involving the photos all failed and I got a Resource Not Found error and when I looked at the stack trace, at first I was just stunned.

My reaction:

  1. Did I mess up the path?
  2. Did I mess up syntax?
  3. Ctrl+Z, Ctrl+Z, Ctrl+Z…
  4. Nope… Still failing
  5. Why does it say it’s not there?
  6. Open a file browser
  7. The photos are gone!
  8. Wait! I get it (derr)

Can you guess what I did?

Spoiler Alert!

I deleted an actual project resource from within the test. It ran fine the first time, but when I came around for the second run, that file was deleted.

file.destroy()

This code actually destroyed the physical resource, something I thought surely would not be possible from inside a test. Maybe it’s a flaw on their end, but I’m chalking it up to just plain dumb on my end. I laughed pretty hard, and thought I’d shared this with the world

Lesson: Be careful what you destroy in your tests. File this one under “Dumb things I’ve done”…

Share on FacebookEmail this to someoneTweet about this on TwitterShare on Google+Share on LinkedInShare on Reddit