Thursday, June 21, 2007

It’s more than a catchy term

Every person is different. They have different experiences, backgrounds and interests.

As we work on a team, we learn to compromise and appreciate other people’s opinions. We change and evolve our practices and create ideas together.

On an agile team this keeps improving. On a dysfunctional team, it plateaus or degrades.

We change based on our experiences and dedication to continually improve. This drives our best practices, interaction with stakeholders, technologies and tools.

We improve by changing. We rely on team retrospectives and personal introspection to guide us.

We buy into our efforts. We enjoy progress. We admit failure and move on.

In our world, stakeholders change their minds (or just don’t know), technologies emerge and practices evolve.

Change is an absolute. Adapting to it is agile.

It is not an easy path, just a possibility for success.

Sunday, June 17, 2007

A rose by any other name

Using English to describe a test is quite a challenge. It is demonstrated in the various styles present in the community. My naming conventions, much like my development style, change constantly.

When I first began TDD, my names looked something like this:
public void MethodATest()

Look familiar? What does this test? Well, it gives me a new method. It tells me I have to test all the functions of this method in one test. It does not give business value and does not give any clues when it fails.

This methodology did not last long -- my tests were too large, too complex and tested too many things. When I had a failing test, I had some idea what was wrong because I remembered the method, but my tests did not evolve with my code.

Eventually, my next naming convention looked a little more like this:
public void MethodADoesThis()
or
public void MethodADoesThisWithThat()
or
public void MethodADoesThisWithThatWhenThisIsTrue()
(sometimes this was: public void WhenThisIsTrueMethodADoesThisWithThat())

Although this naming was more descriptive, it was slightly ambiguious, drove too much design in a single test and was not easily read.

The anatomy of a test is basic, there is a setup of preconditions (context), execution of the code (call method), and then verification process (Assert or Verify).

What if our name told us what to put in each part. Would you know how to write it? Would you know what its testing?

Back in February, Aaron made a post about loosly coupled mocks. His naming convention is great. Its simple, has clear rules and forces you to think about what you are testing. It not only follows the anatomy of the test, but puts you in your test before you write it.

What it looks like:
public void Method_Context_Expectation()

So, for the simple hello world test:
public void GreetTheWorld_Always_CallsConsoleWriteLine

Always is a weird context right? Well, its true and writing it helps understand what you are designing.

Now, what if we want to add a condition to calling GreetTheWorld?

Say we only greet the world, if the world exists:
public void GreetTheWorld_WorldExists_CallsConsoleWriteLine
public void GreetTheWorld_WorldDoesNotExist_DoesNotCallConsoleWriteLine

This naming convention also helps us understand when to use SetupResult instead of expectations. In the methods above, we are using the world as context, and the console as verification so we would say SetupResult.For(theWorld.Exists) instead of expecting it -- we don't want our test to fail from context, only when our expectations are not met.

Another nice thing about this convention is detecting smells in my design. If I have 10 methods for GreetTheWorld, because there are many contexts or expectations, I'd know GreetTheWorld had too many responsibilities.

Who would have thought a simple naming convention could have helped so much, thanks Aaron -- or rather the unnamed person Aaron stole this from :P

Thursday, June 14, 2007

Oxygen is Hiring!

We're looking for some software developers to join our team, check out the description here.

Interested parties, send your resume to Luke

Tuesday, June 12, 2007

Boo

Ayende is always doing some cool stuff with Boo! I really need to check it out.

He recently pointed out some very nice xml support.

For a whole lot of documentation (and introductions) about Boo go here

It has a really great name too :)

Saturday, June 9, 2007

I taught my husband TDD today

(Scott left a comment that made me edit this post a bit)
In less time than it took me to write this post. Can you believe that?? He learned to drive design. He got it!

We started our lesson when I was writing another post about TDD (big surprise, right?). He said I should post some examples. I said that my examples wouldn't be useful without the reactions of the audience. Everyone learns differently.

He gave me a simple example to do, test drive a class that writes "Hello World" to the console. I started explaining what makes this simple problem not so easy to test and we decided to try out the example together.

Asking questions is a great tool to help someone learn, it makes the learner realize conclusions. Figuring out the right questions is always difficult and this morning was no different.

I asked lots of questions. They were focused on one thing: How can I make the introduction of a mock organic?

Eventually he suggested we put Console.Writeline in our CUT, then we refactor it to be testable.

This made me realize my questions were not right.

I needed to teach him how to think in the test. I knew this was a major key how I learned TDD, but I thought it was an evolution.

I was wrong.

In this moment, I realized that learning TDD isn't about writing tests. Its about leveraging polymorphism to verify responsibilities and interactions.

Once I realized this, I only needed to ask one question:
Is there a way we can put something between our CUT and the System.Console to verify the right method was called?

In a few minutes we had an IConsole and a MockConsole implementation. A few minutes later we had a working test, a minute after that we had a console application that wrote hello world.

During his implementation of MockConsole, he found many limitations. After we had a working application, we went back in the test and replaced MockConsole with a RhinoMock.

In the end, he understood how the test drove his design, why it did, why he used a mock and appreciated a mocking framework.

It was awesome.

I'll let his reflection on his learning speak for itself:
I really like TDD. The code you end up with is really good. Its the minimum amount of code to write to make your code testable. The difficulty between just programming and test drivent development is very different...

On the first day of college, you write hello world straight to the console without any understanding of coding, its the real basics.

On your first day of TDD it takes a few layers in between to do it right, its geometrically more complicated, but its only adding a some subtle difference, like IConsole. It gives you the round trip of object oriented programming with simple examples that really illustrate why you do the things you do with object oriented programming. It really takes a great understanding of OOD to appreciate TDD and do it right.

Deciding what tests to write and how you write them are hard, harder than writing the code.

Thank you, that was nice.

Friday, June 8, 2007

Agile 2007

On Wednesday August 15th, The Gentle Art of Pair Programming can be experienced in its entirety at Agile 2007.

Ken, our VP of development and Ilio, our client proxy, will discuss the team's collaboration and experience with our product owner and CEO, Gerry Laybourne.

Agile 2006 was a great conference. With our contributions, Agile 2007 is sure to be a blast!

Wednesday, June 6, 2007

My take on the Joel Test

During our Pair Programming BoF at DevTeach, we discussed our setup at Oxygen. There are no cubes, phones, personal trinkets, just one large table, a bunch of docking stations and a build bunny. In this environment, we are setup for osmatic communication and pairing -- not to mention a great sense of team and fun.

We said this is a great environment for pairing and development and someone said, that's not what Joel said. Jeremy Miller's response was, "Joel's wrong," and until I read Jeremy's recap I didn't he was talking about joelonsoftware Joel. I assumed the person who spoke went to another session at DevTeach where someone was talking about the ideal development environment.

After reading Jeremy's recap and thoughts, I gave the test some thought. Like Jeremy, I like the questions. Who doesn't? But if you are a strong developer in the right position and environment, couldn't you make those things happen? Sure, they're great to walk into, but if you're walking into an environment that is ridgid and has issues beyond your control, you have a much larger problem then setting up a build environment or proving sufficient qa costs less than lacking qa.

Yes or no questions give me pause as well -- I find it easier not to disclose information or to even lie to myself if asked a yes or no question. I'm sure other people do too. Do you have a QA department? Well, Joe the summer intern and Rita and junior developer did a bit of testing before our last release so, yes. When asked to describe my QA environment, they don't seem to hold up well.

Now Joel says in his description of the big 12 that these are just guidelines and there are great teams that don't have any and poor teams with all -- he has a lot of good things to say and the popularity of his blog demonstrates that. However, some people take his list as absolute and that is a bit of a smell.

So, how do you determine if a company is right for you?

Every person is different and has different goals and needs -- are you up for a challenge, do you need a mentor, do you want to work on a team, do you want to be agile, can you promote change, do you want to promote change, what technology do you want to work with, what type of projects interest you, what type of people do you like, what scares you, what risks are you willing to take, what kind of responsibility do you want, what motivates you, what satisfies you, why have you left jobs in the past, what failures have you encountered and why, what successes, where were you most happy and why.

Wow, that is a lot of questions! There are a lot more, because self realization and goal determination is really, really difficult. You need to be honest with yourself. Many people do not like their jobs. For some it doesn't matter because its just something that makes their home life possible. For others it lingers with them long after they leave the office.

If you change jobs when at a time of desparation, try not to lie to yourself. Finding a job that is a perfect match is probably not an option, but if you understand your goals, you can determine your best questions to ask and an environment that will keep you satisfied.