Mountain Lion + Git + Case Insensitive filesystem == headaches

I learned this the hard way after upgrading to Mountain Lion and finding that the case insensitive filesystem was the default.  Though applications (IntelliJ, console, Finder) visually displayed to me my filenames with the characters in the case that they were created in, other applications (GIT) did not register that I had made a refactoring to the filename where the only change was the case.

What I ended up with was a git commit that included refactored classes that referenced the newly changed case in a filename, but my git commit did not pick up that the file itself had changed.  I scratched my head, said it works for me, puzzled why jenkins could not find the file when I clearly see it locally and it’s not being identified as a new change.

To get around this confusion for any development that I do, I created a partition just for my code repositories called “workspace”.  With Mountain Lion, you can run “Disk Utility” to partition your existing hard drive.  Define your new partition, use the “Mac OS Extended (Case-sensitive, Journaled)” format, and ensure that all code/development work is done on this case sensitive aware partition.

One less headache.

Cucumber Goodness

I manufacture my own fairy dust. It’s a special blend of Cucumber goodness and a few of my own secret ingredients. I have to admit though, it’s not a perfect formula. I try to sprinkle the stuff on everyone I come into contact with on my project. Some people are able to shake it off pretty easily. Others can’t imagine how they thrived before without it.

In my magic kingdom we are using Cucumber to breakdown our story into scenarios. It’s a process that we do before development that we call our BDD sessions where we pull in the QA, Developer, Dev Lead, and BA to outline our scenario titles and define our Given, When, Then steps. During this session we uncover all sorts of goodness:

- spikes for architecture concerns
- questions for the PO to clarify requirements
- shared understanding and interpretation of the story
- tasks / questions for the developer owning the story to address

After the session, we publish our feature file as a pull request in GitHub where the entire team has an opportunity to review. Our BA creates a task for each scenario, and works through any open questions. Developers work through each scenario, moving the scenario task to completed once the code and tests have both been completed. In my ideal world (the fairy dust formula and our Continuous Delivery isn’t quite strong enough yet), after every scenario is completed our QA tests and provides immediate feedback.

If our QA finds a defect, it typically identifies a scenario that we missed during our BDD sessions. We create a new scenario for the defect, and we’re more likely to consider that scenario in future BDD sessions.

As a Dev Lead the biggest benefits that I receive are:

- Dev Done is when all scenarios have been completed. This definition doesn’t change based on the developer.
- Requirements live alongside the source code. No hunting through old project tickets or emails containing excel spreadsheets.
- High confidence level that new development isn’t breaking existing features.

Having lived in my magic kingdom for over a year now, I have run into a few trolls:

- Higher ramp up time for new developers
- More time spent on test code for some Devs than actual code
- minimal Cucumber tooling and IDE support
- initial reluctance of BAs to give up their excel spreadsheets

I’m pretty happy in my kingdom but am always looking for ways to improve. Next goal is how to get closer to CD.

IntelliJ IDEA – enable Java 1.4 assertions for Junit Run/Debug configurations

I recently ran into a test discrepancy where my test was failing when running it via the maven surefire plugin, yet it passed when I ran it through IntelliJ’s JUnit runner.

After spending a ridiculous amount of time on this issue, I was finally able to pinpoint the discrepancy to the Java 1.4 introduced “assert” statement and the differences in the default behavior of the maven surefire plugin and the IntelliJ JUnit runner.  The maven surefire plugin (v 2.7.2) enables JVM assertions by default.  IntelliJ’s JUnit runner does not (v 9.0.4).  My test in question happened to be failing due to a failing assert in an included xml parsing library.

To change the default behavior of the JUnit runner, edit the Run/Debug configurations, select Edit Defaults, select JUnit, and add “-ea” or “-enableassertions” to the VM parameters.