Why My GroovyConsole Wouldn't Open

For a few weeks now, I've been wondering why I couldn't launch the pretty version of GroovyConsole on my home computer, but could on my work computer. It turns out this is a bug: http://jira.codehaus.org/browse/GROOVY-3655. Groovy needs the 32 bit JDK to launch. Nore more batch hack, I can now launch the GroovyConsole.exe directly. (Though they still haven't built this for the updated versions -- I assume they're holding off for the 1.7 release).

Problem was, at work I need to use HermesJMS which needs JAVA_HOME to be the 64 bit version (doesn't make sense, but it works). What to do? Fortunately, HermesJMS uses a batch file for its invocation, so just add

JAVA_HOME=C:\Progra~2\Java\jdk1.6.0_16

to line 23 (or anywhere in the beginning, really). Done.

Answered: Using variables in XmlSlurper’s GPath

Yesterday I asked this question about using variables with XmlSlurper. I got an answer that works (although I don't see it anywhere in the documentation or the book Groovy in Action. Below is the example the answerer gave

def xmltxt = """
<file>
<record name="some record" />
<record name="some other record" />
</file>
"""

def xml = new XmlSlurper().parseText(xmltxt)
String foo = "record"
return xml."${foo}".size()

Test Oriented Development

The other day I had an idea. Probably a bad idea, but its something I feel more comfortable with than diving straight into TDD. The rules are

1. You are encouraged to write the test first, but are not forced to.
2. You may not write more than one method without a test.

This way, you write tests as you are writing code, you might write all your test first, but you will never write too much code that isn't tested (assuming you don't cram it all into one gigantic, godlike method). I dub it TOD (Test Oriented Development).

Integration Testing

My colleagues and I have been learning a lot about testing this week. One of my friends' thoughts are here. He asks the question of whether it is a unit test if the method in question calls other methods. I agree with him and would argue that no, it is not, since the culprit is unclear if the method fails (until you go into debugger). Arguably, this could be worst for code that is properly refactored. This is something I don't think code coverage tools will help you recognize.
StackOverflow has some good definitions of unit and integration testing here, and here. I like Michael Feathers' definition:
A test is not a unit test if:

• It talks to the database
  
• It communicates across the network
  
• It touches the file system
  
• It can’t run at the same time as any of your other unit tests
  
• You have to do special things to your environment (such as editing config files) to run it

Josh Brown, a colleague of mine, also suggests adding:

• the code under test uses an external framework or library (Hibernate, Spring, some internal library, etc.)
  
• the code under test calls other methods (that you didn't mock)

I wholeheartedly agree with both of these.

I had a case that was interesting to me. I was working on some code that I've become the caretaker of to get it better tested (a good thing too, as a bug was discovered). The project takes big files and chunks them into smaller files. It handles any xml or delimited file. The way I was testing it was to take different types of files, chunk them then merge them and make sure the record counts stayed the same. This isn't really (even if I had more granular asserts) a unit test. It relies on an external resource (the sample files) and involves multiple methods. Someone else suggested unit tests using files loaded through classpath, which I disagreed with since they're not really unit tests. Those File objects should be mocked (or possibly stubbed if using Groovy).

I did attempt to make these an integration test with FailSafe. I decided against this when I figured out that I could not override the behavior to not run the integration test on deploys. In my opinion, these should not be run on deploy, integration-test should be later in the Maven lifecycle. The reason for this is that deploys are often done across different environments and the whole idea with integration tests is that they depend on external resources. An example of this is a project my friend is working on, which works with the dev database, where it would be fine to run the integration tests on deploy, but when it is deployed to prod, we definitely don't want to modify our production database as part of running tests. To continue to be able to access the QA environment or dev environment would mean adding special firewall rules. What's more, when I set the configuration to skip the tests, it ran the tests anyway (maybe this is why it's alpha?). According to their documentation, it shouldn't have even run the unit tests. I just don't feel quite comfortable deploying something so young and apparently unstable into production code. Maybe someday this will change. There are some other suggestions here. The page he links to from Codehaus states that there are rumors of a future version of Maven supporting integration tests with a src/it/java and its own integration-test phase. Its kinda surprising that with so many organizations using continuous integration and it not being something all that new.

In the end, I decided to do what others have done, which is to have the integration tests in a separate module that is only built if the argument is passed for it.
The parent pom should have

<profiles>
  <profile>
  <id>integration-testing</id>
  <activation>
  <property>
  <name>it</name>
  <value>true</value>
  </property>
  </activation>
  <modules>
  <module>sampleProject-integration</module>
  </modules>
  </profile>
</profiles>

Also, do not list it in the modules section. This way, the integration module will only be built (and the associated surefire tests run) when the -Dit argument is present. I think for most projects, this makes sense for most projects, though I'm still a little torn on the issue. While Failsafe lets you still build even if the integration test fails, doesn't this defeat the purpose of continuous integration? This is especially the case if your integration tests depend on resources that may be going up and down all the time, it doesn't make much sense to run something every time if half the time you just ignore the results anyway. I also wonder how practical this is for organizations that have resources on multiple subnets, where a deploy from one environment to another can result in failed integration tests not because of any problem with the code, but because of a technical failure.

The next part (and for me, the harder part) will be mocking out (and maybe stubbing with Groovy's metaclass) the pieces needed so I can isolate the methods in the classes for unit tests, as there currently aren't any for this project. I'll post any interesting results I get from that. For other initiates, such as myself, I've found this article helpful: http://martinfowler.com/articles/mocksArentStubs.html.

GW2 Update (well, sorta)

Yesterday ArenaNet put the Test Krewe page back up and gave some small hints at forthcoming GW2 news. They've posted a shiny swf on their homepage to be: http://www.guildwars2.com/, created a facebook page: http://www.facebook.com/GuildWars2, and a twitter account: http://twitter.com/guildwars2. All indicators that they're preparing to release some news. Probably nothing as dramatic as a date yet, but we should at least get a trailer and some concept art. Maybe even some discussion about the professions (my prediction is that it will be the core professions from GW1 or very similar, based on the fact the shaping of the world has cut off Tyria from Cantha and Elona).
The related GWGuru page is here: http://www.guildwarsguru.com/forum/showthread.php?t=10395760. Mostly people are excited (those that haven't left the game anyway) though some other pages lurking on the internets weren't as generous.
Am I peeing my pants excited? No. But as I've said, I do think little tidbits, even if they're contrived and only give the illusion of progress (which I don't think these will be) are an important part of keeping a feeling of aliveness in the community.

The Taste of Cha

I've resumed my habit of regular consumption of green tea. Every time I do, I think of the legend of how green tea came about:

Bodhidharma set about meditating for nine years facing a wall. After five years he was so sleepy that he could not keep his eyelids open and fell asleep. When he woke up he was so angry about this that he cut of his eyelids and threw them on the ground. The eyelids grew into the first green tea plants. And from henceforth, tea has ever been the companion of monks for mediation (and apparently for geeks and programming as well).

It is said that "the taste of tea (cha) and the taste of Zen (Chan) are the same". In Japanese, the characters for 'tea' and 'eyelids' are both 'cha'.

mmmmmm.....cha tastes good.

Massive EMP

I've often wondered: If a massive EMP (from a nuke or whatever) were to go off, wiping out all our technological achievements (silicon chip designs, computer languages, etc), how long would it take for us to rebuild? Is the knowledge mostly inside us? Or are we standing on the soldiers of giants to such an extent, we would have to invent the wheel all over again?