Job History

I was going through a bunch of college papers and such the other day and stumbled across an old resume that I put together for my college writing class. Given my current work situation, it was interesting to see that my last break in work was 20 years ago. I wanted to capture this info for posterity.

06/93 - 09/93	Ruff-Tuff Data Products	Delivery Driver
09/94 - 02/95	Cinemark Theaters	Concessionist/Ticket Sales
10/94 - 02/95	Identity Properties	Front Desk Clerk
10/95 - 02/96	Equifax	Authorization Agent
02/96 - 07/01	University of Utah-DCE	Receptionist/Front Desk/Lab Tech
07/01 - 01/07	Myriad Genetics	Programmer I/II/III
01/07 - 01/15	Partnet	Senior Software Developer

Gung Ho

Watched this movie this past week at Movie Night.

Side note: Movie Night is this great thing we've been doing with 2 of our couple friends so they're 6 of us in total.  On a biweekly basis, we rotate from house to house each couple taking a turn a picking a movie.  We start after the kids are in bed.  I couldn't tell you the original criteria for the movies we watch and it really doesn't matter since it's now down to whatever the host wants to show.  Anyhoo... lots of fun and we've seen a number of movies we wouldn't normally see.  Additionally, it's allowed us (Jo and me) to watch more movies than we normally would have.  These days, we rarely see anything that isn't animated.

So, Gung Ho.  It's been a number of years since I had seen this show, and it's held up rather well I must say.  Funnier now that I'm old enough to get more of the adult humor, and still applicable for the times.  Keaton is great in it and Gedde Watanabe is great too.

The Gervais Principle

Jeff, a friend on mine, pointed me to a blog post today (The Gervais Principle) and suggested that I read it.  It's actually a series of posts and I've only read the first one.  I've added the others to my reading list.  Some of the quotes that I thoroughly enjoyed.

So why is promoting over-performing Losers logical? The simple reason is that if you over-perform at the Loser level, it is clear that you are an idiot. You’ve already made a bad bargain, and now you’re delivering more value than you need to, making your bargain even worse.  

He knows his under-performance is not sustainable, but he has no intention of becoming a lifetime-Loser employee anyway. He takes the calculated risk that he’ll find a way up before he is fired for incompetence.

He is oblivious to the fact that the Sociopaths use Powertalk as a coded language with which to simultaneously sustain the (necessary) delusions of the Clueless and communicate with each other.

I'll post a bit more (or intend to) as I dive into the others.

What's in a Name?

I would think most, if not all, men my age will find the following conversation quite funny. Did I really just use the phrase "men my age"? Oh dear.

friend: random thing:
    me: k
friend: there is a new employee here at my work
friend: her name is sarah connor
    me: awesome
friend: i asked her... her last name is by marriage
friend: i told her otherwise she might have had the coolest parents in the world
    me: heh
    me: and a son who'll save the world
friend: yeah i did tell her that when she has a kid she has to name him 'john'
    me: would be tempting fate otherwise
friend: lol
friend: we've all taken to calling her by her full name
    me: like she doesn't want that on her conscious
friend: yeah you can only do so much to change the fate of the world
    me: "Is this the cube of Sarah Connor?"
friend: lol
friend: i know, i say that about everything
friend: no one calls her sarah, its always 'sarah connor'
friend: i ran into her in the parking lot the other day … 'is this the car of sarah connor?'
friend: she does at least have an updated hairstyle
    me: damn
    me: how many pullups can she do?
friend: only 10...
friend: behind the head ones
friend: oh wait, that was 'vasquez'
    me: ha! of course

2012 Election Eve

I've tried to keep most of my political thoughts to a minimum lately (primarily because I haven't felt like they were encouraging any beneficial communication), but on the eve of the 2012 election, I wanted to say a few things.

Regardless of who wins the election, I have no allusions that they alone will solve all our problems or drive us off the cliffs of destruction. The President does not rule the world, write all the laws, pick winners and losers, etc. I hope and pray that whoever is elected tomorrow is inspired and committed to helping lead this nation forward and will work to heal the divide that separates much of our society. I believe our country to have significant un-tapped potential and that the contentious differences that divide us as a nation threaten that potential. Working together, we are far more capable than we are as individuals, interest groups, political parties, etc.

As human beings, we should be able to bridge differences and foster common interests. We are more alike than we are different. As Americans, we should look at our nation's history and realize the dangers of a divided society. Encouraging division distracts us from addressing the challenges that face us. We need to come together rather than continuing to drift apart. Given the time of night... that is all.

Political Tests

I had a funny encounter with one of my more distant cousins at the family reunion.  He said I have a trustworthy face and should run for politics.  He asked if I had ever thought about it and said I should talk to another of our cousins about his political connections.  Knowing my political leanings and the fact that they're on the other end of the spectrum from cousin #2, I thought he (cousin #1) was joking.  The look on my face must have given away my dismay at his suggestion because he then asked me if I was a democrat to which I gave my typical response, "I'm a left leaning independent".  He looked at me like I had 2 heads for a moment and then asked if I've ever taken a political test to determine my position.  I hadn't and didn't think I needed to.  I took a few minutes last night to find and complete 2 such tests.  No real surprise in the results.

First one: http://www.politicalcompass.org/test

Second one: http://www.theadvocates.org/quiz

Link to quiz results

Third one: http://www.people-press.org/typology/quiz/

Gas Prices

I just heard an interesting news story on NPR about why gas prices are going up. No, they didn't blame the President so settle down. Yes, the sanctions in place to hamper Iran from exporting its oil has lowered global supply, but it turns out the U.S. is actually exporting more oil than we're importing because of the low cost of natural gas in the U.S.  Additionally, they said a bunch of oil refineries have closed this year.  Quite interesting.

State of the Union Facts

Does anyone know how to fact check any of these?
• Since the last SOTU, the economy has created 1.9 million private sector jobs.
• The top 1 percent take home 24 percent of the nation’s income, up from about 9 percent in 1976.
• Private sector job creation under Obama in 2011 was larger than seven out of the eight years Bush was president.
• The top 1 percent of Americans own 40 percent of our country’s wealth while the bottom 80 percent owns only 7 percent.
• Thanks to the Affordable Care Act, 2.5 million young adults gained health insurance.
• For every one job opening, there are four people looking for work.
• Last year, China spent 9 percent of its GDP on infrastructure. The U.S. spent 2.5 percent.
• 2.65 million seniors saved an average of $569 on prescriptions last year thanks to the Affordable Care Act.
• Union membership is at a 70-year low. • Unemployment benefits have lifted 3.2 million people out of poverty.
• The United States used to have the world’s largest percentage of college graduates. We’re now #14.
• One quarter of all contributions to federal campaigns come from 0.01 percent of Americans.
• 47.8 percent of households that receive food stamps are working, because having a job is not enough to keep them out of poverty.
• In the last three years, 30 major corporations spent more on lobbying than they paid in taxes.
• 50 percent of U.S. workers make less than $26,364 per year.
• More than one in 70 homes faced foreclosure last year.
• Since 1985, the federal tax rate for the 400 wealthiest Americans dropped from 29 percent to 18 percent.

Garage Work Bench

So I love my garage (I don't know how I lived without one for so many years - ignorance was bliss), and I've somehow managed to fill it quite nicely. It makes me wonder where all this stuff lived before I had such a nice storage location. In the garage along one side, I have these built in shelves which are quite handy. However, after the first few months of living here, I noticed I didn't have anywhere to put things when I was looking through some of the stuff on the shelves. One of the things that I'm always pulling off the shelf to look through is my container of nuts, bolts, nails, screws, etc (every man should have at least one of these things). Anyway... I found myself using my (gasp) car hood as a place to set things. Less than ideal. What I needed was a work bench, but I didn't want to build anything too grand and didn't want to dedicate the floor space to something either. So I came up with an idea I thought would work. I have to say that I'm quite pleased with how it turned out.  I had the piece of plywood laying around.  I had to buy the chains, the carabiners, the hinges, screws, and bolts.  I think it cost me around $10.

Moneyball

Had a chance to see this over the weekend at the $1.25 theater.  Earliest movie time I've ever been to of 10:20am.  Nice quiet theater with all of 6 other people or so.  Yes, not the nicest theater, but it didn't change the film I'm sure.

A very good movie, and I'm certainly not a baseball fan.  Yes, I've seen a bunch of  baseball movies (The Natural, The Sand Lot, The Rookie, Major League, League of Their Own, For Love of the Game, Field of Dreams, The Fan, come to mind), but my wife too enjoyed it and she's no sports fan.  Brad Pitt and Jonah Hill were both very good in it.  Sorry, ladies... Brad kept his shirt on the entire movie (Jonah, too, remained fully clothed).  It was nice to see Jonah in a film where he isn't playing the same role he seems to.  Did you know BTW that Jonah Hill is the voice of one of the characters from How to Train Your Dragon?  Me either.  It was a surprise when I saw that on imdb.

Candide

Author: Voltaire
After I finished reading The Last Symbol, I needed another book, but didn't have a chance to pick anything up.  We were headed out of town and I thought I'd have some time to read.  I didn't want to take what I was reading at the time, The Power of Pause, because I wanted something different.  We have quite a few books around the house including a bunch of "classics" that we've acquired over time.  I've attempted to read a few of them in the past, but really struggled to get into them.  I needed something though and Candide looked short enough that I didn't think it would be too much of a commitment.

Needless to say, I didn't have the time while out of town that I thought.  So foolish of me thinking I'd have time for myself while on vacation with my boys.  Not that I'm complaining.

Anyway... Candide was more dense than it appeared.  It was easy enough to read as far as the language went, and it contained numerous historical references and footnotes, which were interesting at times.  It was odd in how the timeline of the book raced and paused.  One sentence would be describing a conversation about the struggles of life and the next would say something like "Candide and his company arrived in Portual two months later."  Huh?  What just happened to the conversation.  I can't say I got anything from the book other than the satisfaction of having finished one of the "classics" that's been sitting on my shelves.

Reservoir Dogs

This had been on my list of movies to see (again) for some time (Apr 2009).  Jo and I finally watched it about a month ago thanks to Netflix.  After watching it with Jo, I felt like I had to apologize.  I think the way the movie was filmed was cool and the plot is engaging, but it didn't live up to the spot on the pedestal I had placed it in my memory.  Maybe I'll have to talk to Jeff more about it's appeal.

The Power of Pause

Becoming More by Doing Less

Author: Terry Hershey
Loyola Press

We heard Terry speak in Seattle at the EE convention in 2010 and really enjoyed his presentation. The idea of slowing down some to smell the roses struck me and this book talks about finding the sacrament and grace in all the ordinary of our daily lives.

While the book was quite different than I thought it was going to be (I expected it to be more of a self-help book), I certainly got a different perspective from it, and I'm sure Terry would agree that it's not intended to be a self-help book.

EasyMock Fundamentals

Introduction

EasyMock is a mock library that can be used as a supplemental tool for a testing framework, such as TestNG, to improve unit testing implementations. EasyMock provides the means (through the use of mock objects) to specify the response that will be returned when the code being tested makes calls to external methods. This will allow the result of the unit test to be isolated from variables outside of the scope of the unit test code.

Refer to the official EasyMock documentation for more detailed explanation of the tool (latest as of this writing EasyMock3.0.Docs).

Note: For the sake of simplicity, not all the details of the code examples have been included.

What is a mock?

Short concise description:

Mocking and Mock Objects is not specific to Java. Mock objects is a unit testing technique in which a code chunk is replaced by dummy implementations that emulate real code. This helps one to write unit tests targeting the functionality provided by the class under test. - reference

For more information, this article offers very good introduction to the concept of mocking:
Mock Objects.

Stubs vs. Mocks

An alternative to using a mock object is to create a stub object; a lightweight implementation of the interface for the external methods, that just return the expected response. These two approaches are best illustrated with an example.

Let us say you want to write a unit test for an object Foo that does something cool, doSomethingCool(), and uses another object, Emailer, to send emails while doing something cool as follows:

package com.partnet.foo;

public class Foo {
  private Emailer emailer;

  public Foo(Emailer emailer) {
    this.emailer = emailer;
  }

  public void doSomethingCool() {
    // something worthy of being unit tested

    emailer.sendEmail(...);
  }
}

package com.partnet.foo;

public interface Emailer {
  boolean sendEmail(...) throw EmailerException;
}

If you're trying to test the doSomethingCool() method, you don't want to, shouldn't have to, and thankfully don't need to worry about what emailer.sendEmail() does (assuming the implementation of the call has no impact on the code you're testing of course).

The assumption here is that the real implementation of Emailer, say it's called FancyEmailerImpl, is a non-simplistic object that may require some configuration or won't work in a non-real environment. In this case you do not want to have to create a real FancyEmailerImpl and use it in your testing because again, what it does has no bearing on the code you're actually trying to test.

Stub Objects

Using the stub object approach, you could create a stubbed-out/dummy version of Emailer like the following:

// stub object
package com.partnet.foo;

public StubEmailer
  implements Emailer
{
  public boolean sendEmail(...) throws EmailerException {
    return true;
  }
}

Simple, easy, done... right? Yep, you can now just setup your unit test as follows and test away:

// stub object use
package com.partnet.foo;

public TestFoo {
  @Test
  public void test() {
    Emailer stubEmailer = new StubEmailer();
    Foo myFoo = new Foo(stubEmailer);

    myFoo.doSomethingCool();
  }
}

The downside to this approach is that you end up building and maintaining a bunch of stub code. Additionally, stub code can be difficult to write as you get into stubbing out more complex objects that you want to test around. For example, if the code you're testing sets an ID on your Emailer and later retrieves it via setId()/getId() methods, this behavior would need to be stubbed out correctly.

Mock Objects

The alternative to writing stubs is writing mocks, or more correctly, using a mock object library to create mock objects for you. EasyMock is such a library. The following demonstrates how to use EasyMock to mock out the Emailer from above.

// mock object example
package com.partnet.foo;

public TestFoo {
  @Test
  public void test() {
    Emailer mockEmailer = EasyMock.createMock(Emailer.class);
    Foo myFoo = new Foo(mockEmailer);

    myFoo.doSomethingCool();
  }
}

Simple, easy, no stub code to maintain. Even cooler is how you solve the problem mentioned above regarding setId()/getId(). This is where the concept of Expectations comes in (in terms of EasyMock, these are called IExpectationSetters). An Expectation is basically you telling a mock object how to behave and what you expect to happen when you run the unit test code: "When this happens, do this", "When your getId() method is called, return this value", "I expect that your setId() method will be called". After your unit test code has run, you can then ask EasyMock to verify that everything you expected to happen actually occurred so that you can be assured your code does what you think it does.

Downloads

The latest EasyMock files can be downloaded from a link on the EasyMock Download page.

Integration

Add these to the classpath:

• easymock.jar
• cglib (2.2) - to perform class mocking
• Objenesis (1.2) - to perform class mocking

EasyMock only works with Java 1.5.0 and above.

Writing Tests

Basic steps for EasyMock use

1. import EasyMock
• import static org.easymock.EasyMock.*;  // non-static imports may also be used
2. create mock object
• private ClassOrInterface mock;
• mock = createMock(ClassOrInterface.class);  // throws AssertionErrors for all unexpected method calls
• mock = createNiceMock(ClassOrInterface.class);  // allows all method calls and returns appropriate empty values (0, null or false)
3. specify expectations for mock (in other words, "I'm going to tell you what you should expect to do")
• mock.doThis();
• mock.doThat();
• specify that the last method could be called x times
• expectLastCall().once();  // default one call
• expectLastCall().times(3);  // exact calls
• expectLastCall().times(2, 5);  // min, max calls
• expectLastCall().atLeastOnce();  // one or more times
• expectLastCall().anyTimes();  // 0 or more times
• specify method response or return value
• expect(mock.doThis()).andReturn(returnValue, i.e. "true");
4. make mock available for use (in other words, "I'm done telling you what you should expect to do, now get ready to do it.")
• replay(mock)
5. run unit test that will call doThis() and doThat()
• verify proper response
• assertTrue(doThis());
6. verify that expected behavior was called (did everything get called the expected number of times?)
• verify(mock)

Tips

Prefer Nice Mocks

There are basically 3 different ways to have EasyMock create a mock object for you.

1. createMock(Foo.class)
2. createNiceMock(Foo.class)
3. createStrictMock(Foo.class) 

Each way gives you a mock object with slightly different behaviors/restrictions. Consult the EasyMock API for specifics, but unless you have valid reason to not, the preferred method is createNiceMock(). Nice mocks are, as their name suggests, 'nice'. 'Forgiving' is probably a more appropriate term in that, as the API states, nice mocks will return 0, false, or null for unexpected invocations. Meaning:

• for methods that return int, double, long, char, float, byte, short (non\-boolean primitives) - the returned value is 0 
• for methods that return boolean (not sure about Boolean) - the returned value is false 
• for methods that return Object (or anything that extends Object) - the returned value is null 

The benefits are not obvious without further explanation. Try to think of it in these terms. Nice mocks allow you to configure them the way you want for the behavior you care about without having to configure them for the behavior you don't care about and are not relying on for your test. For example, let's assume you want a mock for an object that has a getId() method. Chance are you don't care what getId() does and if the code you're testing doesn't care what it does, but happens to call it in a log statement or something that is irrelevant to your test, then a nice mock will allow you to not have to setup an expectation for that method (see Example 1).

package com.partnet.foo;

public class Foo {
  private Emailer emailer;

  public void doSomethingCool() {
    // I don't care about this and don't want to setup an expectation for it
    log.debug("emailerId:" + emailer.getId());

    // something worthy of being unit tested
    emailer.sendEmail(...);
  }
}

Additionally, if another developer were to remove that log statement, the unit test wouldn't have to change because the expectation was never added and the tests wouldn't break just because a log statement was removed.

Prefer "Relaxed" Expectations

The term "relaxed" refers to the IExpectationSetters API as it relates to configuring the number of times an expectation is valid. Specifically, the methods once(), times(count), and times(min, max) should be avoided unless you really care and/or your test relies on them. The methods anyTimes() and atLeastOnce() should be used instead. These "execution count" methods set the number of times a given method is expected to be called. The reason the latter methods should be preferred is that, while setting up explicit method call counts is certainly valid, implementations change over time and often times those changes have no effects on the functionality of a given object. For example, who cares how many times emailer.getId() is called in the above example and does the fact that it gets called multiple times have any effect on the calling code? Clearly not. However, if an expectation like the following was added:

EasyMock.expect(mockEmailer.getId()).andReturn(1).once();

and later the log statement was removed or an additional log statement was added that called getId() again, the unit test would fail.

However, this practice is not an across-the-board standard as it makes sense to setup an expectation like the following:

EasyMock.expect(mockEmailer.sendEmail(...)).andReturn(true).once();

because sending multiple emails is most likely not expected or okay.

NOTE: not specifying one of the "execution count" methods is the same as using the once() method (i.e. once() is assumed unless otherwise instructed).

Stub Returns

andReturn() vs. andStubReturn()

EasyMockSupport

Introduced in version 2.5.2, EasyMockSupport is your friend. It saves you the trouble of having to call reset(), replay(), and verify() on all your mock objects. As the javadoc shows, an example usage is as follows:

package com.partnet.foo;

public class TestFoo
  extends EasyMockSupport {  // this is key

  @Test
  public void test() {
    resetAll();  // reset all existing mocks

    // create mocks
    firstMock = createMock(A.class);
    secondMock = createMock(B.class);

    replayAll();  // put all mocks (new & existing) in replay mode

    // use mocks

    verifyAll();  // verify all mocks (new & existing)
  }
}

Mock Builders

See [some future post] for how cool this feature is.

Argument Matching

Argument matching is related to setting up expectations and is one of those subtleties of EasyMock that you might miss and certainly not understand until you really start writing tests.

The following shows setting up an expectation without any argument matchers:

EasyMock.expect(mockEmailer.sendEmail("foodaddy")).andReturn(true);

In this scenario, you're telling EasyMock to return true when sendEmail() is called with "foodaddy" as the parameter. Simple enough, but what if you wanted tell EasyMock to return true for all parameter values, or only certain parameter values, or only on Tuesdays, etc? This is where argument matchers come to play.

The following demonstrates an argument matcher that matches all String values:

EasyMock.expect(mockEmailer.sendEmail(EasyMock.isA(String.class))).andReturn(true);

What about all String values except "foodaddy"?

EasyMock.expect(mockEmailer.sendEmail(

    EasyMock.not(EasyMock.eq("foodaddy")))).andReturn(true);

EasyMock supports a wide selection of argument matchers that can be used to create any type of matcher. Here are some of the matcher methods:  anyInt(), anyObject(), contains(), eq(), geq(), gt(), isA(), leq(), lt(), same(), startsWith().

Argument matchers can be combined using the following methods:  and(), or(), not()

Consult the API for a complete listing, but as an example:

// true for "foodaddy" or "foo.*daddy"
EasyMock.expect(mockEmailer.sendEmail(
    EasyMock.or(EasyMock.eq("foodaddy"),
        EasyMock.and(EasyMock.startsWith("foo"),
                     EasyMock.endsWith("daddy")))
        )).andReturn(true);

EasyMock even has support for creating custom argument matchers. Consult the API for more info. For more info on argument matchers, see this blog post.

Argument Matching part 2

EasyMock has this annoying feature/limitation that prevents mixing non-argument matchers (raw values) with argument matchers when setting up expectations. I often encounter this when trying to setup expectations for a method that takes multiple parameters where some are simple primitives and others are complex types. This can be annoying because often times you want to be able to setup your expectations in this way. Given the following:

public interface Emailer {
  boolean sendEmail(String emailAddress, String message);
}

public class Foo {
  private Emailer emailer;

  public Foo(Emailer emailer) {
    this.emailer = emailer;
  }

  public void doSomethingCool(boolean useDefault, String emailAddress) {
    String message = null;
    if (useDefault) {
      message = "default message";
    }
    else {
      message = "something else";
    }
    emailer.sendEmail(emailAddress, message);
  }
}

So now you want to test this code so you start as follows:

public class TestFoo {
  @Test
  public void test_doSomethingCool()
  {
    final String emailAdrs = "foo@foodaddy.com";

    Emailer mockEmailer = EasyMock.createMock(Emailer.class);

    // return true when emails are sent to foo@foodaddy.com
    // regardless of the message being sent
    EasyMock.expect(mockEmailer.sendEmail(
        emailAdrs, EasyMock.isA(String.class))).andReturn(true);

    EasyMock.replay(mockEmailer);

    Foo myFoo = new Foo(mockEmailer);
    myFoo.doSomethingCool(true, emailAdrs);

    EasyMock.verify(mockEmailer);
  }
}

As the comment above states, you don't care what message is being sent to "foo@foodaddy.com". You want all emails sent to "foo@foodaddy.com" to return true. Seems valid enough, but when you run your test, you'll get an error message similar to this:

java.lang.IllegalStateException: 2 matchers expected, 1 recorded. This exception usually occurs when matchers are mixed with raw values when recording a method: You need to use no matcher at all or a matcher for every single param:

Huh? The key is "..._matchers are mixes with raw values_...". Unfortunately, you can't do what you were hoping to do. EasyMock requires that you use ALL raw values or ALL argument matchers in a given expectation. So the following shows how you accomplish this:

public class TestFoo {
  @Test
  public void test_doSomethingCool()
  {
    final String emailAdrs = "foo@foodaddy.com";

    Emailer mockEmailer = EasyMock.createMock(Emailer.class);

    EasyMock.expect(mockEmailer.sendEmail(
        EasyMock.eq(emailAdrs), EasyMock.isA(String.class))).andReturn(true);

    EasyMock.replay(mockEmailer);

    Foo myFoo = new Foo(mockEmailer);
    myFoo.doSomethingCool(true, emailAdrs);

    EasyMock.verify(mockEmailer);
  }
}

The eq() argument matcher is what's needed here and is especially handy at matching primitive values. The eq() argument matcher can certainly be used to match more complex types, but with primitives, you don't have to worry about the implementations of equals() and hashCode() as discussed next.

Captures

These are cool, but the documentation and examples I've found are not. I like examples so hopefully the following will demonstrate Capture's coolness. Given the following:

public class Recipient {
  private String name;
  private String email;

  public Recipient(String name, String email) {
    this.name = name;
    this.email = email;
  }

  // getters for above attrs
}

public interface Emailer {
  boolean sendEmail(Recipient r, String message);
}

public class Foo {
  private Emailer emailer;

  public Foo(Emailer emailer) {
    this.emailer = emailer;
  }

  public void doSomethingCool(boolean useDefault) {
    Recipient r = null;
    if (useDefault) {
      r = new Recipient("foodaddy", "foo@part.net");
    }
    else {
      r = new Recipient("noreply", "noone@part.net");
    }
    emailer.sendEmail(r, "some message");
  }
}

So the question is, how would you test the doSomethingCool() code and ensure that the if/else conditional evaluation is being done correctly? Granted, this is a simple example, but the question is still valid. There are 2 possibilities.

• 1) Implement equals() and hashCode() on the Recipient object so that their implementation, specifically equals(), could be used in your unit test as follows.

public class TestFoo {
  @Test
  public void test_doSomethingCool()
  {
    {
      Recipient recOne = new Recipient("foodaddy", "foo@part.net");
      Emailer mockEmailer = EasyMock.createMock(Emailer.class);

      // this next line is the key - we're relying on the fact that
      // recOne.equals(recipient) == true - where recipient is the
      // one created in doSomethingCool()
      EasyMock.expect(mockEmailer.sendEmail(recOne, ...)).andReturn(true);

      EasyMock.replay(mockEmailer);

      Foo myFoo = new Foo(mockEmailer);
      myFoo.doSomethingCool(true);

      EasyMock.verify(mockEmailer);
    }

    {
      Recipient recTwo = new Recipient("noreply", "noone@part.net");
      Emailer mockEmailer = EasyMock.createMock(Emailer.class);

      // same comment as before
      EasyMock.expect(mockEmailer.sendEmail(recTwo...)).andReturn(true);

      EasyMock.replay(mockEmailer);

      Foo myFoo = new Foo(mockEmailer);
      myFoo.doSomethingCool(false);

      EasyMock.verify(mockEmailer);
    }
  }
}

As was noted in the code, the key is that we're relying on the implementation of Recipient.equals().

On the test code line:

mockEmailer.sendEmail(recOne, ...);

two things are occurring:

1. You are setting up an expectation that the sendEmail() method will be called
2. The Recipient that is passed to sendEmail() will be equal to the one provided. 

Even though the same Recipient object instance (recOne != recipient) is not used in the expectation, the two different instances are considered equal:

recOne.equals(recipient) == true

By not including an argument matcher explicitly, EasyMock is using object equality (equals()) to match. This is the same as using the eq() argument matcher.

While this approach is certainly valid, it's less than ideal because it requires that equals() be implemented. Furthermore, the implementation of equals() has to be known and understood how to be taken advantage of (i.e. you have to know that name and email are used in equals() rather than something like an id attribute). Additionally, you're not able to actually test/assert against the attribute values of the created Recipient. That's essentially what's being done by taking advantage of the implementation of equals(), but it's less explicit and obvious to the poor maintenance developer.

• The second (and better) approach is to use an EasyMock Capture as follows to retrieve, err capture, the actual instance of the Recipient object created by the doSomethingCool() method.

public class TestFoo {
  @Test
  public void test_doSomethingCool()
  {
    {
      Emailer mockEmailer = EasyMock.createMock(Emailer.class);
      
      Capture rCap = new Capture();

      EasyMock.expect(mockEmailer.sendEmail(
          EasyMock.capture(rCap), ...)).andReturn(true);

      EasyMock.replay(mockEmailer);

      Foo myFoo = new Foo(mockEmailer);
      myFoo.doSomethingCool(true);

      EasyMock.verify(mockEmailer);
      
      // actual Recipient instance returned here
      Recipient recipient = rCap.getValue();
      
      Assert.assertEquals(recipient.getName(), "foodaddy");
      Assert.assertEquals(recipient.getEmail(), "foo@part.net");
    }

    {
      Emailer mockEmailer = EasyMock.createMock(Emailer.class);

      Capture rCap = new Capture();

      EasyMock.expect(mockEmailer.sendEmail(
          EasyMock.capture(rCap), ...)).andReturn(true);

      EasyMock.replay(mockEmailer);

      Foo myFoo = new Foo(mockEmailer);
      myFoo.doSomethingCool(false);

      EasyMock.verify(mockEmailer);

      // actual Recipient instance returned here
      Recipient recipient = rCap.getValue();
      
      Assert.assertEquals(recipient.getName(), "noreply");
      Assert.assertEquals(recipient.getEmail(), "noone@part.net");
    }
  }
}

Using a Capture has none of the requirements/drawback/quirks as the first approach and is certainly no harder to use.

Links

• EasyMock Home 
• IBM article
• Slideshow tutorial

Worry

My Dad was always telling me not to worry about Jess when we were younger and he (my dad) was around.

So we're all (CJ, Alex, Jo, me) downstairs last night picking up toys... except Alex of course is playing with toys.  Christopher keeps telling Alex to stop playing because it's time to pick up.  I tell CJ to relax that mommy and daddy will take care of Alex.  CJ continues to be bothered by Alex's playing.

CJ: Alex, STOP playing!
Me:  Christopher, don't worry about Alex.  You worry about you.
CJ: But I have to worry about Alex because he's my baby brother.

The tears of joy swell in my eyes... and as I write this.

Wise Words of Tecumseh (Shawnee)

This was read as part of my uncle Gary's funeral service:

Live your life that the fear of death can never enter your heart.
Trouble no one about his religion.
Respect others in their views and demand that they respect yours.
Love your life, perfect your life, beautify all things in your life.
Seek to make your life long and of service to your people.
Prepare a noble death song for the day when you go over the great divide.
Always give a word or sign of salute when meeting or passing a friend, or even a stranger, if in a lonely place.
Show respect to all people, but grovel to none.
When you rise in the morning, give thanks for the light, for your life, for your strength.
Give thanks for your food and for the joy of living.
If you see no reason to give thanks, the fault lies in yourself.
Touch not the poisonous firewater that makes wise ones turn to fools and robs their spirit of its vision.
When your time comes to die, be not like those whose hearts are filled with fear of death, so that when their time comes they weep and pray for a little more time to live their lives over again in a different way.
Sing your death song, and die like a hero going home.

Garileo Pedroza

Hubs and Dad
Kearns, UT-Gary was born September 6, 1956 to Frank and Beverly Pedroza in Murray, Utah he married Ann in 1981 and they have two wonderful sons, Philip and Issac. He is the third of four brothers. Although he is free of the pain of arthritis, it was not a peaceful passing. He fought like hell to stay as he felt that he had work to do and that he needed to take care of his little family, multitude of friends and cohorts. His passing has left a large hole in many people and places. He left us all way too early. He is preceded in death by his parents. Survived by his wife, sons, brothers and a multitude of aunts, uncles and cousins.
 
Gari grew up in Kearns, Utah. He attended Kearns Jr. High and was student body president, inspiring many, and helping transform the Kearns High graduating class of 1974 into one of the closest classes ever. Gari went on to graduate from the "U" in planning, working as an intern for SLC and then as a planner at Price, Utah. As the arthritis began to take a toll on his body, he worked from home turning his "avocation" into his "vocation", consulting and connecting people on various projects relating to his geometries with the intent of helping the world.
 
Gari loved camping and the mountains. Because he could no longer hike he had to content himself with driving to the various vacation areas, speeding by rest areas with a vengeance! Everyone learned quickly not to drink any beverage while on the drive with "G"!
 
Gari always honored Christmas and kept it in his heart the whole year. It is appropriate that he left with the angels this time of year.

The Last Symbol

I've decided I need to start keeping track of the books I read.

Author: Dan Brown
Much like the other books by Brown that I've read (The DaVinci Code and Angels & Demons) which isn't saying much as it involves the same character, Robert Langdon. I certainly enjoyed the book and was able to breeze through it quite rapidly including some late nights where I couldn't put it down.  Brown's short chapter switching back and forth between plot lines contributes to that quite a bit. It made we want to go back to Washington DC for another trip and see some specific sites.

Halloween Hat

Jo has put out a few Halloween decorations around the house including a couple plastic witch's caldrons.  Today, Christopher decided that one in particular makes a great hat.  He was playing with it on his head and decided to push to down all the way... all the way, over his ears and eyes.  He thought that was pretty funny.  Thing was though that it was tight fit so when it came to taking off his head, he kinda started freaking out and really struggled with getting it off.  Additionally, he want any help getting it off so Jo and I sat there laughing hysterically.  I looked for the camera, but wasn't fast enough.

Dizzy Trucks

Christopher calls cement trucks "Dizzy trucks".  Yes, I know there's a Bob the Builder character that is a cement truck called "Dizzy", but I still think it's cute.