EasyMock - Not?

I'm generally not a huge fan of mock object frameworks in unit tests. I do use mock objects (and stubs and fakes, too), but most of the time I prefer to create my own, perfectly suited to the task at hand. I think it is the result of my strong desire to be in control of everything. If I write the mock, I know what it is doing and can be confident that it does the appropriate thing. However, I recently had the opportunity to explore JDBC and I wanted to do a thorough job with jUnit without actually testing inserts and updates to a live (or even a real, but test) database. I decided to try EasyMock so that I could assert that the appropriate calls were being made on the various SQL objects and since it seems difficult to create stand-ins for things like java.sql.Connection and java.sql.PreparedStatement.

It took longer to get up and running with EasyMock than I expected. The documentation included with EasyMock is sparse, and I took that to mean that its use would be trivial. Further, documentation I found on the Internet seemed to outline multiple approaches. Some described creating the mocks directly, others first created a control and then used the control to create the mock. I think, though, that the various approaches parallel the evolution of EasyMock. Older versions did things one way, and the newer version (3.0 in my case) may do them differently. For one just getting started, this variety made things confusing.

Eventually, though, I had what I thought was a basic, functioning test. When it ran, however, the error messages seemed cryptic and complicated. I had to do some additional Internet searching to decipher these messages and fix their causes. Add to that the fact that one message (NoClassDefFoundError) indicated that one of the necessary libraries was missing from the build path. There was nothing wrong per se in the test. I found a fix here.

Finally, I reached a point where I began to understand what was happening, and I was able to really experiment with the structure of the tests and the mock objects. I had expected to reach this point quickly (after, say, 30 minutes). Instead, it took several hours, and it was only that I was determined to see this through that I didn't give up and begin searching for another approach. That certainly isn't what I expected from a tool whose name starts with "Easy."

In the end, though, I'm intrigued with EasyMock and the concept of mock object frameworks in general. I can see how they can be used to test some things that would be difficult to test otherwise. I'm still struggling with the fact that the tests seem to focus on the specific and precise implementation rather than the overall outcome, but when testing that a given method generates the proper PreparedStatement by setting each argument with the correct value, for example, that focus on the details of the implementation may be exactly what is required. Now that I know how to incorporate EasyMock into a project, I'll be able to further explore how it might be used successfully to augment other approaches I use in unit testing.

The Role of an Agile Tester

Recently, I was asked about the day-to-day role of a tester within an Agile software development environment. The role of the tester is going to depend heavily on the overall structure of the Agile/Scrum team. In some environments, the testers are expected to be an integral part of the team, and that is, in my opinion, a very good thing. Other times, though, testing remains an after-the-fact activity that occurs once the programmers have finished their work. I think that Agile is difficult to implement successfully in this kind of environment.

I believe that one must look at the tester's role from both the day-to-day and the over-time perspectives. The day-to-day perspective should emerge from an understanding of how the testing emphasis changes over time. In the beginning of the project, the testers will be engaged primarily in creating (or fine-tuning) the automated test infrastructure. Due to the pace of Agile software development, automated testing becomes extremely important. Otherwise, the testers will not be able to test as thoroughly as they might like in each iteration, and the project will incur a significant amount of technical debt that must be addressed prior to release. (Think about large manual regression test suites that cannot be run within each iteration but which must be run before each release. This sort of manual testing is particularly difficult in an Agile setting.)

As the project gets underway, testers will work to create test plans and test cases for upcoming iterations. The goal is to have these test plans and test cases defined before the developers start work on the stories they are intended to test. That may not be entirely possible in reality, but it does help to have as many of the tests written as possible so that they provide the programmers with a clear and unambiguous definition for "done."

Over time, the emphasis shifts from infrastructure and test creation toward test execution. The tester's role shifts to automating existing test cases and performing manual exploratory testing on the evolving and maturing application. Automated tests are run regularly, ideally as part of each automated (or at least nightly) build, and they help to provide the comprehensive regression on the mature parts of the system. The testers need to be able to focus on the parts of the application that have just been implemented.

Life in the World of Social Networking

I don't know how people do it. Blogs, Twitter, Facebook - all technologies I'm just starting to use and already I wonder how people manage to keep up. I find it difficult to complete all of the things I had to do before I signed in to Web 2.0.

Maybe I make too many things into big productions. I haven't yet learned to tweet as things go on around me. I find that I have to make a conscious effort and plan out what I want to say. I'm the same way with other, less technical projects, too. I sometimes have trouble starting a task because I am unable to work out how I might finish it. My rough drafts are generally very close to a final copy because I wouldn't start until I had most of it written in my head. I don't like to make mistakes, and a scratch out in raw notes or a rough outline may cause me to toss it out and start over. That's probably just a bit obsessive.

Another stumbling block for me is that I feel that I need something I consider important to relate. I wonder why people care about what I'm doing right now. I suspect that reflects a certain amount of insecurity. Perhaps I shouldn't care so much about whether others care about what I'm doing.

I think the secret to successful social networking may be in finding ways to capture casual comments and observations as they happen in the same way that you might point something out to a friend who is physically with you at the time. Just as some people keep idea notebooks handy to jot down those sparks of inspiration that occur when least expected, others have their mobile phones ready to tell the world what's going on. Also, when you're with a friend, you often say whatever pops into your head. It may be irrelevant or unimportant or even something really weird, but it might start a conversation, a debate, or some other kind of personal interaction. That's probably part of the purpose behind social networking initiatives - allowing people to interrelate despite spatial separation in ways that resemble what's possible with colocation.

Why the Challenger Exploded

Lessons Learned From
Col. Mike Mullane’s Keynote
at STPCon Fall 2009

I was asked to present at the Software Test and Performance conference (STPCon) held the week of October 19 in Cambridge, Massachusetts. The conference was great - full of energy, enthusiasm, and lots of people wanting to learn how to do thorough testing in Agile environments. One of the things I enjoy most about attending these conferences is the opportunity to talk with and listen to others. Everyone has a unique background and can share personal experiences that are both interesting and educational.

One of this year’s keynote speakers was Colonel Mike Mullane (ret.), a West Point graduate who was commissioned in the Air Force and ultimately flew three Space Shuttle missions as an astronaut at NASA. He spoke about teamwork fundamentals, and he emphasized three key components:

• normalization of deviance
• responsibility
• courageous self-leadership

Here, I want to explore the first two.

According to Mullane, normalization of deviance is the natural human tendency to take shortcuts under pressure. When pressed for time, people rationalize and justify why they are unable to meet expected standards. If they see no immediate negative consequences from their actions, they come to believe that the standards were originally too high and were unrealistic. “The absence of something bad happening when deviance was accepted means it was safe to do so,” explains Mullane. This is false feedback, but, because nothing bad happened, the shortcut becomes the norm.

Ironically, in a no-pressure situation, people tend to hold themselves to the original, higher standards. Failure at that point in time is intolerable. When the pressure rises, though, failure comes to be expected. There’s just too much to do. In the effort to get it done, people cut corners and make exceptions. Others accept the deviance, again, because nothing bad has happened. (Interestingly, around this point in his presentation, Mullane noted that it seems there’s never time to do a thing right, but we always find time to do it again. This is something I've pondered in the past, and I find it to be an interesting facet of human behavior.)

Mullane shared with the audience some facts not generally known about the events that led to the fatal disaster with the Space Shuttle Challenger in the middle 1980s. What most of us do know is that an O-ring seal failed, allowing intense heat and flame to go places it was not intended to go. What we don’t know, though, is that engineers at the NASA contractor who designed and built the solid booster rockets knew this could happen. They had seen the same O-ring damage after previous flights. (The boosters are recovered and inspected after each flight.) Some urged NASA to ground the shuttle fleet until the problem could be properly analyzed and corrected.

NASA, though, was under intense pressure to make the shuttle flights successful. In this case, “successful” meant one flight every two weeks - a grueling schedule to try to maintain. And, since nothing bad had happened, grounding the fleet was unnecessary. Doing so would be overreacting. Clearly, the O-rings were over-designed and the specifications were well beyond what was truly necessary to ensure the safety of the crew and the vessel. We know now that these justifications were hollow; there was a real danger, and, deep down, everyone knew it. Just over a minute into the flight, the O-ring failed completely and the Challenger exploded. Mullane called this a “predictable surprise.” NASA knew that it could happen, but they were very surprised when it actually did.

To overcome this tendency to cut corners and take shortcuts, everyone must realize that he or she is vulnerable. “Plan the work and work the plan,” says Mullane. The standards are established in times without schedule and delivery pressures, when people are better able to think clearly. The corners are cut when time is short, pressure is building, and people are less apt to think things through. Mullane stresses that you must execute to meet the standards, and you must adopt a “situational awareness” that enables you to react to the environment and adjust the plan accordingly. This reminds me of a quote I really like from General Dwight D. Eisenhower:

“In preparing for battle I have always found that the plans are useless, but planning is indispensable.”

(And while searching for that reference, I found this one by General Collin Powel:

“No battle plan survives contact with the enemy”

and this one by General George S. Patton:

“A good battle plan that you can act on today can be better than a perfect one tomorrow.”

That second one may be worthy of a future post.)

Coupled with the natural tendency to normalize deviance is a tendency to remain silent in the face of opposition. People choose not to take action for a variety of reasons:

• they don’t like confrontation
• they want to be accepted
• they fear rejection
• the members of the opposition are their friends
• they assume someone else will take action
• they do not believe it is their place to take action
• they are afraid of their supervisor

Mullane told a story about a flight in an F-111 fighter/bomber where he was the navigator. In that role, it was his job to tell the pilot when they were low on fuel. He did, but the pilot said “We have one more mission objective. We’re going to complete that first.” In this case, the pilot had hundreds of hours of flight time in the F-111, but Mullane had logged only 30 or so minutes. He accepted the pilot’s decision without even a word. As you might be able to guess, they ran out of fuel on approach, and they were forced to eject. Both survived, but the plane did not. Mullane’s advice: “Never become a passenger.” He had surrendered his responsibilities and was nothing more than a passenger in the airplane. Instead, he says, everyone has a responsibility to take action when the project is in jeopardy.

The lessons here are very clear, and I believe I can summarize them in just two sentences. First, don’t talk yourself into lowering your standards in the face of pressure. Second, when you see something you know is wrong, do something about it. Avoid the normalization of deviance and accept the responsibility to address it when you see it.

If you want to learn more about Mike Mullane, visit his website at http://www.mikemullane.com. To learn more about STPCon, see http://www.stpcon.com and http://www.stpcollaborative.com.

What's with the title?

I love to start new and projects, but I'm easily distracted and generally prefer to start another new thing rather than complete one already in progress. Further, I enjoy dabbling in many subjects: computer programming and programming languages, Agile software development and testing, spoken and written languages, music, and workplace efficiency to name just a few. That list could go on and on. I fancy myself a Renaissance man, and it frustrates me to have so little time to act on all that I wish I could do.

Such a diverse collection of interests leads me to ponder interesting topics and the interrelationships that may exist between them. My hope is that this blog will become a forum where I can express those thoughts and ideas, possibly attracting input and feedback from others. The title, "Musings, Ramblings, and Unique Perspectives," sets the tone for what may be pointless commentary on a variety of things I see or experience in the world around me.