Retrospective by Peter Seale
It's done, it was a success. We had most of the room participate on the "presenter" laptop (i.e. the one running the projector.) Some others followed along on their own laptops. Some watched (which is fine.) Joe recorded the session and can maybe get the video to you if you want it badly enough, but hopefully we won't post a video anywhere publicly (to encourage future participation.)
I'll start out the retrospective by saying:
· We wrote our tests in the smallest 'baby steps' increments possible, and I think everyone stuck to the "babysteps" rule. This was great. Baby steps isn't something that comes naturally to me, but it seemed like less people were fighting it tonight.
· It occurred to me that we weren't as dogmatic about following the red/green/refactor steps. Specifically I'm not sure everyone made sure their tests failed before implementing the code that would make the tests work. Still, we did awesome on the baby-steps, "simplest thing that works" aspect.
· I wish we had pre-written a console test harness so that we had tangible results from the start. Our "static void Main(char[] args)" method remained empty all the way through to the end. We could have done the console implementation during the dojo, and mostly via TDD, but that would have probably been 2 hours in itself given our pace.
· I wish we had a better way to tie this small TDD exercise into a larger picture of how you write applications. But, the less talking, the more time for practice. Read a book on your own time :)
· As we always do, we argued about the design :). If you don't believe me, post a question to the group asking how to record failed login attempts.
· Our end result was somewhat ugly, which is sad. It's okay because everyone stayed true to the focus of the dojo, which is to practice red/green/refactor TDD in the smallest increment possible...but the code needed cleaning up by the end, both tests and the system itself. If you don't swap out for a new "lead architect" every 7 minutes like we did at the dojo, presumably your code will turn out less schizophrenic.
· JB had a good question about whether we should set up proper contexts for each test, and JP said in an offhanded reply (don't quote him on this) that he can get remarkably far without doing mocking or interaction tests. I've compared JP's tests to my own context/specification-style tests, and I'll say, even though I'm totally sold on context/specification, JP's tests are simple and straightforward. You can't beat simple and straightforward. Anyway this was a fascinating discussion for me.
· I want us to split up into smaller groups, but the danger there is that we'll lose the group mentoring. So, by "want" I mean "maybe want," or "ideally want." There you go, my stream of consciousness. Feel free to fire away on your thoughts.
Code
To answer your question I'll point you at the parallel implementations of the User Login code. Compare JP's all-encompassing 5-line tests to mine, or to the Pablo's tests with their many test helper classes.
Mine ("untainted" as I didn't look at the Pablo's implementation before doing this myself; needs cleaning): http://code.google.com/p/pseale
Comments (11)
Alper said
at 8:03 am on May 8, 2009
Yeah, the code we ended up with wasn't done. We didn't expect it to
be done, did we? And of course it wasn't even a great implementation
of what we DID write. But we came in with the goal to practice TDD
and I felt like we did a pretty good job of it. I thought if we kept
going down the "strict" rules, we'd have eventually ended up with
prettier code. I'd re-read the transcript at
http://www.objectmentor.com/resources/articles/xpepisode.htm right
before coming tonight and I tried to stick to what I'd seen there as a
good example of how it will work. I think we really did manage to
follow that practice.
In the future, maybe we might want to have a dojo that concentrates on
something other than TDD, where we could feel better about the code
that was produced. But honestly, strict TDD provides a great set of
simple rules that really suit the "dojo" style of learning. Follow
these simple rules as strictly as possible and you WILL improve. It's
like Mr. Miyagi forcing you to do a simple repetitive motion when
you're desperate to go kick someone's ass in a fight. .
But I'd definitely vote for smaller groups. We'd just have to make
sure to split the groups up carefully so as not to end up with one
group that has a significantly better experience than the other.
Since the goal of this is to practice, I really think people need more
chances to get to the keyboard. And with less people there are less
distractions-- you're more likely to be a participant even if you're
not standing up in front.
Thank you again for taking the initiative on setting this up. I am so
excited to have met a group of people who show a passion for truly
improving their coding skills.
JakeS
Alper said
at 8:03 am on May 8, 2009
I thought last night went really well. I really learned a lot. What stood
out for me most was that people really got "simplest thing that works" (at
our Sogeti dojo's we are still fighting that battle here and there).
I wasn't happy with the code at the end but I think that it is really good
thing....because after talking with Chalice I think we came up with the last
piece of the puzzle needed to make these dojo's successful.
So, here it goes. Right now, we are basically throwing our pilot and
co-pilot to the wolves. It is up to them to figure out a test and write the
code. The problem with this is that we are changing our "lead architect"
every 7 minutes. The code speaks for itself as to why this is a bad idea.
Fortunately, there is a simple solution to this problem.
We need to decide what we are going to do next as a group! When the pilot
and co-pilot go up, they should be implementing what we have all decided
must be done. I am sure we will see better code quality as a result of this.
If this is not enough by itself, Jared had the idea to have a refactoring
iteration - every 5 turns or so - where the sole purpose was to clean up the
code. However, if we are all driving the design every turn, I am not sure
this will be necessary.
I think that taking the guess work out (by doing group design) will also get
more people comfortable with participating. People will know what needs to
be done before they get to the keyboard. I'd like to hear what you all think
about this, because I want to start working to get another dojo set up soon.
J.P.
Alper said
at 8:03 am on May 8, 2009
@Peter: I want the video badly :)
@JP: I like the idea of having the pilot and co-pilot implement what
the group have decided.
I don't want to start another debate, just have a question.
I believe we should set up proper contexts for each test. Can we setup
proper contexts by naming without using spec and mocking frameworks
complicating things?
I'm basically thinking about naming TestFixtures/Test to provide a
context for each test.
A test fixture named like:
When_authentication_service_is_asked_to_authenticate_user_with_valid_credentials
sets up a context for the tests no?
What do you think?
Alper said
at 8:04 am on May 8, 2009
To answer your question I'll point you at the parallel implementations of
the LoginContext code. Compare JP's all-encompassing 5-line tests to mine,
or to the Pablo's tests with their many test helper classes.
- Pablo's (original) http://code.google.com/p/daysoftdd
- JP's (based on Pablo's): http://code.google.com/p/jphamilton
- Mine ("untainted" as I didn't look at the Pablo's implementation before
doing this myself; needs cleaning): http://code.google.com/p/pseale
Also ask Joe (Joe Reynolds) about the video. He mentioned last night that
the audio wasn't coming through, but, anyway, if you're interested...
Also if anyone is willing to publicly post their code, I'd love to look at
it...comparing parallel implementations of this small problem has been
fascinating.
Peter
Alper said
at 8:04 am on May 8, 2009
Do we need to take all of these emails and create a "Houston Coding Dojo #1"
wiki entry?
J.P.
Alper said
at 8:48 am on May 8, 2009
@Peter when I said "context" I was not referring to the MSpec context. I was thinking about context in a generic sense -condition in which the test will execute-.
As far as I can see, JP's tests are already setting up proper contexts.
In the following test name "with_valid_user" is actually establishing the context.
should_return_true_with_valid_user
Peter Seale said
at 11:11 am on May 8, 2009
Yeah maybe I wasn't answering the right question. Maybe what I mean is: completely rewrite one of our tests into that method and post the result, and then we'll talk :)
Peter Seale said
at 11:17 am on May 8, 2009
Re-read your question: The one part where frameworks start to matter for me is when you get to more complex scenarios and you need complex contexts that inherit from simpler contexts. I thought I needed to do this context inheriting thing on this LoginContext problem, and then I looked at JP's tests and he did all this without needing anything too crazy. So maybe I just need to look around and try to do simpler setups instead of just jumping into setting up independent contexts.
I don't know. The jury's still out.
In related news: I'll definitely try another test framework at the next opportunity, and go with the leanest thing possible (MSpec is syntax craziness.) I'm thinking XUnit with the test class named as you described above.
joe reynolds said
at 11:18 am on May 8, 2009
I will get the video cleaned up and post a link sometime this weekend.
JP - Wiki would be a great idea I bet.
Alper said
at 12:02 pm on May 8, 2009
I'm working on some tests I will post them soon.
Alper said
at 12:49 pm on May 8, 2009
I added AuthneticationResult class. This may be overkill but I could not resist.
http://code.google.com/p/alper/source/browse/
You don't have permission to comment on this page.