{"id":1502,"date":"2010-09-26T11:32:13","date_gmt":"2010-09-26T20:32:13","guid":{"rendered":"https:\/\/www.kellyrob99.com\/blog\/?p=1502"},"modified":"2010-09-26T11:32:13","modified_gmt":"2010-09-26T20:32:13","slug":"groovy-inspecteval-for-externalizing-data","status":"publish","type":"post","link":"https:\/\/www.kellyrob99.com\/blog\/2010\/09\/26\/groovy-inspecteval-for-externalizing-data\/","title":{"rendered":"Groovy inspect()\/Eval for Externalizing Data"},"content":{"rendered":"

One of the things I love about Groovy is how easy it makes reading and writing text files. I’ve written Groovy scripts for everything from parsing log files for extracting timing information to finding (and replacing with selectors) in-line css blocks. Often there’s a piece of information extracted from a file that I want to keep for further examination, or just for future reference. The Groovy inspect()<\/a> method provides a nice easy way to take simple results that are stored in variables and write them to a file. Then the Groovy Eval<\/a> class provides convenience methods to parse that information back from the file in a single line. Here’s examples of test code that creates Lists and Maps, writes them out to a file and then asserts that evaluating the stored Groovy code results in the same data structures.<\/p>\n

\r\n    private static final Closure RANDOM_STRING = RandomStringUtils.&randomAlphanumeric\r\n    private static final String TMP_DIR = System.getProperty('java.io.tmpdir')\r\n\r\n    @Test\r\n    public void testSerializeListToFile()\r\n    {\r\n        List<String> accumulator = []\r\n        100.times { int i ->\r\n            accumulator << RANDOM_STRING(i + 1)\r\n        }\r\n        File file = new File("$TMP_DIR\/inspectListTest.groovy")\r\n        file.deleteOnExit()\r\n        file << accumulator.inspect()\r\n        assertThat(accumulator, equalTo(Eval.me(file.text)))\r\n    }\r\n\r\n    @Test\r\n    public void testSerializeMapToFile()\r\n    {\r\n        Map<String, String> accumulator = [:]\r\n        100.times { int i ->\r\n            accumulator[RANDOM_STRING(i + 1)] = RANDOM_STRING(i + 1)\r\n        }\r\n        File file = new File("$TMP_DIR\/inspectMapTest.groovy")\r\n        file.deleteOnExit()\r\n        file << accumulator.inspect()\r\n        assertThat(accumulator, equalTo(Eval.me(file.text)))\r\n    }\r\n<\/pre>\n
Two little tidbits of goodness embedded in this example are the ability to capture a method as a closure, in this case RandomStringUtils.randomAlphanumeric(), and the File.deleteOnExit()<\/a> method – which is only cool because I never noticed it in the API before and it turns out to be a great way to clean up after tests.
\n\ud83d\ude42<\/p>\n
A particular usage of this technique I’ve been using lately has been sparked by a shift of tools at work. I’ve worked with the Atlassian stack of web applications for years now, and have always enjoyed the rich feedback Bamboo gives for build history. But now I’m using Hudson as the primary continuous integration tool and one of the things I’ve been sorely missing is the ‘Top 10 Longest Running Tests’.  If you’re not familiar with this view in Bamboo, stroll on over to the Groovy build results page<\/a> and click on the tab.
\nOne of my present priorities at work is to speed up build times and rooting out slow or inefficient tests is one way to do this. It’s possible to elicit this information from JUnit test reports using xsl(see this link for an example<\/a>)  but I came up with a nice way to incorporate similar functionality into a Gradle build. Following the Gradle<\/a> project-report conventions, this task simply uses the inspect() method to write out a results file in the ‘reportsDir’. I’ve captured this output(manually) over time to track the progress of speeding up test times, and the format makes it easy to read back in results and do deeper analysis and aggregation – such as the creation of csv reports and simple graphs for instance.<\/p>\n
\r\ntolerance = 2.0\r\ntask findLongRunningTests << {\r\n    description= "find all tests that take over $tolerance seconds to run"\r\n    String testDir = "${project.reportsDir}\/tests".toString()\r\n    file(testDir).mkdirs()\r\n    File file = file("$testDir\/longRunningTests.txt")\r\n    file.createNewFile()\r\n    BufferedWriter writer = file.newWriter()\r\n    writer << parseTestResults('**\/TESTS-TestSuites.xml', tolerance)\r\n    writer.close()\r\n}\r\n\r\n\/**\r\n * Read in xml files in the junit format and extract test names and times\r\n * @includePattern ant pattern describing junit xml reports to inspect, recursively gathered from the rootDir\r\n * @tolerance the number of seconds over which tests should be included in the report\r\n *\/\r\nprivate String parseTestResults(includePattern, float tolerance)\r\n{\r\n    def resultMap = [:]\r\n    fileTree(dir: rootDir, include: includePattern).files.each {\r\n        def testResult = new XmlSlurper().parse(it)\r\n        testResult.depthFirst().findAll {it.name() == 'testcase'}.each { testcase ->\r\n            def key = [testcase.@classname.text(), testcase.@name.text()].join(':')\r\n            def value = testcase.@time.text() as float\r\n            resultMap[(key)] = value\r\n        }\r\n    }\r\n    return resultMap.findAll {it.value > tolerance}.sort {-it.value}.inspect()\r\n}\r\n<\/pre>\n
Note that this works recursively from the ‘rootDir’ of a Project<\/a>, so it is effective for multi-project Gradle builds. Source code for this simple example is available on github<\/a> if you want to check it out yourself.<\/p>\n
Here’s a sample result drawn from examining some test output in the Gradle build itself. Only one of the tests executed in WrapperTest takes more than 2 seconds to execute.<\/p>\n
\r\n["org.gradle.api.tasks.wrapper.WrapperTest:testWrapper":2.37]\r\n<\/pre>\n","protected":false},"excerpt":{"rendered":"
One of the things I love about Groovy is how easy it makes reading and writing text files. I’ve written Groovy scripts for everything from parsing log files for extracting timing information to finding (and replacing with selectors) in-line css blocks. Often there’s a piece of information extracted from a file that I want to […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"ngg_post_thumbnail":0,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_feature_clip_id":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2},"jetpack_post_was_ever_published":false},"categories":[6],"tags":[265,222,219,257,221,223,220,112,113],"class_list":["post-1502","post","type-post","status-publish","format-standard","hentry","category-dev","tag-bamboo","tag-eval","tag-gradle","tag-groovy","tag-hudson","tag-inspect","tag-junit","tag-kellyrob99","tag-thekaptain"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t