YAJUEHP - Yet Another JUnit Exception-Handling Post . . . *yawn*

I can't imagine anyone will find this useful when it is so tiresome to me, but after a jaunt in UI Testing purgatory I had to go back and test some plain old library code, but this time with a new twist.  I have been using the rather awesome ExpectedException class with nice results.  The Code Under Test in this case, however, threw InvocationTargetException's with wrapped cause's which made that approach too brittle.  I found this nice post about it which solved my issue:

JUNIT EXPECTEDEXCEPTION RULE: BEYOND BASICS

Toward the bottom there is a nice discussion of verifying causes.  I found another article he wrote comparing various exception strategies in JUnit here:

6 WAYS OF HANDLING EXCEPTIONS IN JUNIT. WHICH ONE TO CHOOSE?

I thought these were pretty handy - hopefully someone else will as well.

Star(schema) Commander, Iteration 2

I got version 1.1 and 1.2 out in the same night.  I have dimensions and reporting areas, and a mechanism to import dimensions from a database.  Not too useful yet, but facts are coming.

JUnit System Rules

I found this today - it was very helpful for some testing I was doing.

System Rules

It has all kinds of cool stuff in it, but what I was looking for was a way to have tests override system properties (Specifically to test code which relied on user.home) and after each test completes the properties are restored.

Star(schema) Commander, Iteration 1

I have created an API, a maven project, and set it up for maven central synching.  That's not much value, but it is a lot of legwork.

For the next release I am going to aim for at least the ability to create a profile.

Star(schema) Commander, Iteration 0

Because I am constantly writing queries against dimensionally modeled star-schemas, I decided to write a small app to make the process easier.  I thought I would approach it in an agile manner - incorporating small releases and focussing on delivered value.

I also thought it might be interesting to post my experiences mainly to help keep myself on task.  My goal is to have a very usable UI - but I have tried that before and I think it will end up like a messy iOS app with code scattered all over user interface components.  It would also take a long time for me to be able to do anything meaningful - and an application opening a window is not value.  E.G., It might take months to make the UI work, but probably only a few weeks to have a command-line tool I can use to generate queries.  That would be a win by itself.

So, anyway, here I go.

This is the bitbucket project (currently blank):  https://bitbucket.org/bradleysmithllc/star-schema-commander

This is where I will actually document it (also currently blank): https://etlunit.atlassian.net/wiki/display/STAR/StarSchemaCommander

The Opiate of the Masses . . . ?

Karl Marx once said, in effect, that Religion is the opiate of the masses.  To be exact, this is the English translation of the quote according to Wikipedia:

"Religion is the sigh of the oppressed creature, the heart of a heartless world, and the soul of soulless conditions. It is the opium of the people."

I was thinking about this recently because I had an experience which brought this quote to mind, and about how off target this is - at least in our time.

Religion, or Faith?

He was wrong primarily in mistaking religion for faith.  It is tempting to give Marx the benefit of the doubt and assume that he understood the difference, but I don't believe that someone who has never experienced genuine faith in something greater than oneself can really know what it is.  Faith is not a drug to dull our senses and numb our emotions - it is a genuine devotion.

He further believed that he could substitute devotion to the collective - or more specifically the government institution - for a genuine faith.

Why is he wrong?  Because Opium induces a delirious high - perhaps helping the addict to release cares due to the drug.  True faith, however, yields hope - or, in the words of the Apostle Paul:

Galatians 5:22-23
But the fruit of the Spirit is love, joy, peace, forbearance, kindness, goodness, faithfulness, gentleness and self-control. Against such things there is no law. 
Galatians 5:21-24 (in Context) Galatians 5 (Whole Chapter)

If you compare this list to what Opium use produces, the comparison becomes laughable:

• Lying or other deceptive behavior
• Sudden worsening of performance in school or work, including expulsion or loss of jobs
• Loss of motivation and apathy toward future goals
• Withdrawal from friends and family, instead spending time with new friends with no natural tie
• Repeatedly stealing or borrowing money from loved ones, or unexplained absence of valuables
• Hostile behaviors toward loved ones, including blaming them for withdrawal or broken commitments
• Regular comments indicating a decline in self esteem or worsening body image

The true Opiate of our Times

So, if religion is not the opiate of our times, then what is?  I mentioned earlier that an experience I had brought this to mind.  I was feeling a little down at work (combination of stress and disillusionment with lack of ability to finish projects), and I put on some music - specifically Schubert's Winterreise.  I immediately felt an emotional ambivalence - the very effect I had hoped for.  I realized then how we use music in so many different ways in our world - from entertainment to mood alteration and even behavior modification.  Looking at it objectively, there are very few times in our lives when there is complete silence.  Music in the car, in the elevator, when we are on hold on the phone, in movies, blaring at sporting events in between any pause in action, etc.  In fact, situations which lack music seem lackluster and boring.  Clearly this pales in comparison to opium use, but that was Marx's choice, not mine, and I believe it is a more appropriate comparison than religion since the goal of music is similar, even if the results are dissimilar.

Our cultural infatuation with Music-like sounds (Most of the time not musical at all) was demonstrated to me when I went to an OU / Texas game at the Cotton Bowl.  Music was blaring the entire time there wasn't action directly in front of us - and it was horrible.  An acoustic assault on our senses.  Just because I love football, does that automatically mean I like AC/DC??!?!?  I am not sure the intention was even to entertain musically, but rather to incite an intensity and rush that is expected of a big-time football game.  It also aids some drunken fans in getting up for the stupid fights that sometimes occur afterwards.

The worst part is that I have spent a significant portion of my life as a musician, and music lover, which means in affect that I am both a dealer and a user.

Hi.  My name is Brad - I am an addict.

Exceptional JUnit Rules

I recently got aggravated at the JUnit capability for handling and testing expected exceptions.  Usually it looks like this:

@Test(expected = IllegalArgumentException.class)
public void testBadConditions()
{
}

That works just fine when first assembled, but what happens when that same exception class is thrown by a different piece of code, for a different reason?  The answer, the test passes.  This hit me when I was implementing a builder pattern in my etl-unit framework using a TDD approach, and my tests for validating parameters would pass, but when I added more validation the same exceptions were being thrown for different reasons (because I altered the order of validation) so the tests were still passing, but parts of code were being hidden from test cases and were no longer being covered.  When using TDD you tend to lean heavily on the unit tests, and things like this can be a big problem (tests passing when they should not).  I like to know right away when I have broken something.

I had a couple of options that I knew about:

1. I could use a different exception class (or subclass) for each validation rule.
2. I could use try/catch blocks in my tests and manually check the exception class and message.

Option (1) sucked, and in some cases I couldn't do it anyway, so I ruled that right out.  The second would allow me to use distinct messages to make them verifiable, but made for ugly tests (my opinion):

@Test

public void testBadConditions()

{

  try

  {

    causeAnError();

    // in case an exception is not thrown

    Assert.fail();

  }

  catch(IllegalArgumentException exc)

  {

     Assert.assertEquals("expected message", exc.getMessage());

  }

}

I didn't care too much for that - way too much noise in my tests.  I initially googled it and found, as expected, a bunch of irritating, condescending posts about why this is always bad and JUnit would never implement this.  The @Test annotation indeed does not support adding a message, but I have been using JUnit rules a bit recently and I hoped there might be a rule for this.  Suspecting that it would be called ExpectedException, I googled for that.  To my delight, I found it.  Here is an example of the above test using this rule:

@Rule public ExpectedException expectedException = ExpectedException.none();

@Test

public void testBadConditions()

{

    expectedException.expect(IllegalArgumentException.class);

    expectedException.expectMessage("expected message");

    causeAnError();

}

@Test

public void noExceptionThrownTest()

{

 ...

}

I really like the way this looks.  It is functionally equivalent to the previous example.  The declaration of the @Rule is initialized with ExpectedException.none() so that the default state before each test is not to expect an exception, and noExceptionThrownTest does not expect an exception as usual.  Then, at the start of the test, as with other JUnit rules, you tell the rule to expect an exception class and then give it the message to expect.

Other things you can do with this rule are specify a regular expression for the message, and assert an exception cause class type.

I'm not sure I like this better than having it in the @Test annotation, but I do like it way better than my alternatives.