Can't seem to ever finish a post...

Between working and mommying, I can't seem to finish any of my blog posts -- this is bothering me...

So, I signed up for twitter -- wundarous

Maybe I'll get some ideas out...

or maybe it will be random thoughts that make no sense..

Either way, no excuses not to add a sentence here and there!

The need for speed

I say this a lot, but I love TDD. Besides the list of reasons about how it improves code or simplifies solutions, TDD is fast.

TDD is fun because it goes so quickly. Write a test, make it pass, refactor, run more tests.

I love the flow. I love adding a new interface and using it without worry about implementation. I love knowing after I make a new test, something in the app is different and it works. I love living in the tests and only running the application before checking in.

However, the moment the tests slow, the practices start to slip...

1. Writing code and verifying it works by launching the app, then creating the tests
   
2. Making the test pass before verifying it failed.
3. Not running all the tests before check in.
4. Not refactoring because it takes too long
5. It stops you from working close to 5 because you don't want to wait for the build
   
6. Not adding tests at all because you don't want to break the build and don't want to wait to find out
   
7. It ruins all the fun.

These things all lead to poor test coverage or tests that don't actually do what they say. Yeah, on paper your coverage may look nice, but there's plenty of code you can delete w/o breaking tests. Coverage makes sure a code path is followed, it does not verify the path was actually tested.

So, how do we keep our tests running quickly?

1. Mocking. Reduces the amount of time spent creating dependencies and their dependencies and the rabbit hole of dependencies that nobody can even see.
2. Use a one to one ratio of test assemblies to application assemblies -- don't waste time waiting for things to build that you're not testing.
   
3. Keep interfaces and implementations in separate assemblies. Dependents should only be recompiled if the contract changes, not the implementation. This allows you to complete the usage of a change, without worrying about the implementation. Sure, you can just resharper, but are you really going to add tests for a new method right now?? If you do, you break the rhythm, if you don't, you have to remember, somehow, that there is code that needs to be implemented somewhere that your tests won't pick up... you'll start thinking about the implementation or just forget and break the app without anyone knowing.
4. Simplify. Keep tests short. Only create items in setup that are used in all tests. Avoid factories for creating concrete classes because they hide dependencies and make it too easy to use real implementations instead of mocks. Avoid repeating yourself in tests, don't assert the same thing twice, it doesn't help to have the same failure twice but it does slow everything down.
   

In general, follow the best practices of test writing! They're there for a reason. No point in experiencing the pain of the nice people who figured them out. Take advantage w/o having crappy tests, lots of pain and failure.

When Agile Works

When I started consulting on an "agile" team back in February, my first thought was, "Hey! You guys lied! This isn't agile."

The working practices were reminiscent of James Shore's recent blog post.

There was Scrum but they lacked visibility, risk mitigation and self management.
There was a morning stand up, but it was a status meeting with over 20 people -- mostly watchers.
There was a single product team, but members were broken up into domain groups with their own managers, politics and definitions of success.

There were bad practices, communication breakdowns, over-commitment, over-time, half finished features, inconsistency and plenty of technical debt.

Team members had all the stress and no power to change.

But, there was hope.

Within the first few months the company reorganized and moved towards product hierarchy eliminating the contention between groups.

=>Consistent goals and priorities.

The BAs, design and product owner worked closely with an agile coach to create a product backlog. They began having sprint reviews and retrospectives.

=>Visibility and reflection.

A few people became scrum masters. A few others scrum product owners. They started going to agile conferences and local meetings.

=>Engagement.

I left at the end of July to have Kaylee. Things were changing, but we were still far from a well functioning agile team.

When I returned in November, I heard that our agile coach said this was the best agile team he's been on.

I thought to myself, "I think he's been drinking some kool-aid..."

However, when I came in for sprint review and planning, I was amazed.

So much changed.

Team members were involved.

Practice improvements and innovations were made throughout the day.

Charts and metrics were used, not shown.

People were having the right conversations.

The differences not only showed in the team and interactions, but the product.

They had visible success.

I feel very fortunate to have the unique look into the evolution of this agile team.

When you are on the team, it can seem like things don't change. Our retrospectives are a microscopic view compared to a projects lifespan. If I was working for the past 3 months, I may have not noticed.

Maybe a periodic review of how things were/how things are would be a good motivator and illustration of how cool agile can be when its working.

3 Months Later...

Almost.

Babies are challenging... Giving birth was easier... Forget about the note I was sleeping better after Kaylee was born, that didn't last long!

Ah, but the human condition. We adapt. Disrupted sleep included.

Now that I've adapted, I'm consulting again.

Apparently, I really, really like to code AND its much, much easier than being a mommy! Not quite the same ROI...

Since I do most of my work from home, I get the best of both. I'm quite lucky.

I'm with the same company and working with lots of WPF and TDD. We just started using the Isolator AAA from typemock, which looks nice. I know Roy was very involved with its creation and I usually agree with all his testing methodologies :)

My heart is still with rhinomocks, but hopefully I'll find a place for typemock too!

And being a mom, I have to include some newer pics of my lovely daughter!

My Little Wunda

I'm proud to say I'm a mom to a beautiful daughter born Saturday, August 16th. I'd like to thank my great birthing team of my husband, Vanessa (his sister) and my doula, Amy. Between them and hypnobabies, I was able to have an incredible birthing experience!

To keep up with the academic nature of this blog -- I'd like to share what I've learned so far in my few days of motherhood (note, I never picked up an infant or changed a diaper before Saturday)

1. Giving birth was the most intense, satisfying and romantic experience of my life
2. Its better to let your dog lick your infant than a person kiss their face
3. There's all kinds of great feelings for your own child you could never imagine
4. Wearing your baby is lots of fun and lets you do something while they're sleeping other than watching them sleep
5. Its still early, but so far I've been sleeping better than I have in the past few weeks (my husband however, is learning the joys of interrupted sleep)
6. Every person you talk to will give advice and everyone has different opinions on the same things (that goes for doctors, nurses, grandparents and strangers)
7. Babies like loud noises, cry before they go to the bathroom, fart louder than you could imagine and produce incredible amounts of poop!
8. If all you do is breastfeed, change diapers and sooth an infant, it can take you days to write a single email
9. In a single day, your entire outlook, appreciation and viewpoint changes completely
10. Every coo, cry, movement, poop and breath from your infant is precious

Although I'm sure I'll have my hands full, hopefully, I'll get to write some of the posts I had been putting off for the last few months while I'm away from work -- I've had a lot of adventures in WPF and TDD I'd love to share!

TechEd Pair Programing Session Overview

Since the session environment was different from our usual, and the audience's agile experience varied greatly (mostly none or little) we decided to allow the audience to ask questions during the presentation. The most successful pairing environments leverage a strong agile environment, so much of our content relies on certain knowledge of other agile practices.

Since we didn't limit questions we ended up covering the first 5 slides and lots of questions in the first 45 minutes of the class.

Not exactly the definition of a breakout session.

This made some people very happy and some people, well, not.

If you enjoyed the session, I'm really happy it helped! I hope you gained some insight you can take back to your team and good luck!

If you didn't, I hope you left early and gained interesting knowledge elsewhere you could take that back to your team and also, good luck :)

Joe White has posted a great summary of everything covered -- thanks Joe!

Most of the questions we answered would have been covered during the lecture, so if you are worried you missed out on some important information, no worries, you just got it in a different order.

Followup to Testing with Mocks

Thanks to everyone who came to the Testing with Mocks TLC session at TechEd.

Here are some links of things we touched on during the class. Please leave a comment if I missed something :)

Test Smells:
TDD Anti Patterns -- Be sure to read the comments, there are some valuable smells there too!

Books:
The Art of Unit Testing
Working Effectively with Legacy Code
TDD by Example (Kent Beck's book)

Rhino Mocks:
Ayende (creator of rhino mocks)
Google Group
Reference Guide

Other .NET Testing Frameworks:
nMock
TypeMock
Moq

Test Runners:
nUnit
mbUnit

Tools:
Resharper
TeamCity
CruiseControl.NET
CruiseControl.rb

IoC Containers:
Castle MicroKernel/Windsor
Spring.Net
StructureMap

Community:
Alt.Net