TDD

Team Smells...Refactoring For A Better Tomorrow (Part Two)

Blake Caraway — Thu, 30 Mar 2006 20:13:00 GMT

In a previous post I detailed some conditions existing on development teams that would suggest some changes need to be made in order to bring about better performance and ultimately higher quality software. In this post I will identify a couple more Team Smells and discuss how these issues can be remedied and why these conditions should be addressed in the first place.

Smell: Developers Spent Way Too Much In The Debugger (AKA Debugger Junkies)
A good feature-rich debugger like the one that comes with Microsoft Visual Studio is a nice tool. It allows you to easily get a view into the runtime state of your code. Unfortunately, developers can use this tool as the sole form of verification that the code they wrote is functioning properly. There should be one obvious, overriding reason to step through code using the debugger: tracking down a bug (duh!). A valid debugging scenario would entail watching a particular piece of code execute to determine why it’s behaving in an unexpected manner. A Debugger Junkie commonly works in this way:

1. * fingers crossed *

2. Hit F5 and see if the solution compiles

3. Wait for the entire application to load up

4. Navigate to the specific point in the application where the breakpoint or breakpoints are ready and waiting

5. Interact with the application to try and re-create the unexpected behavior

6. When Step 5 uncovers some indication as to where the problem might be, investigate the objects’ state in and around the perceived problem area to uncover the root cause

7. Devise a plan for where the code should be modified to make the feature behave as expected

8. Make code change and GoTo Step 1

Not only is this an unbelievably inefficient way to work, it can often make for a confusing and miserable work experience. No wonder developers on a team that exhibit these smells don’t want/are afraid to modify their code – they are sick of looking at it! Because of the dependency on the debugger to validate their efforts, by the time these junkies have completed a couple medium-sized application features, they are experiencing no small amount of frustration from the debugging monotony they have put themselves through. There _is_ a better way…

Refactor: The key to ridding your team of this poor habit is to implement measures that help developers gain confidence in the code they are producing. Getting a development team to change the way they work and weaning them from the perceived security of the debugger can be a rough ride in the beginning. J. Peterman, of Seinfeld fame, said it best when demanding Elaine help her office ‘boyfriend’ Zach break his drug habit –

“PETERMAN: … Uh, P.S., the first twenty-four hours are the worst. Better bring a pancho.”

Yep, it can get messy. There will be no limit to the number of excuses offered up as to why this new approach won’t work. But Test Driven Development (TDD) is perfectly suited for ridding a development team of their debugger dependency. The very process of creating a unit test before writing any live code provides the developer with an accurate measurement of how the code should work. When code is written to make a unit test pass, there should be a large amount of confidence that the code is doing exactly what it needs to do. When all requirements for an application feature are satisfied by a battery of unit tests – THE FEATURE IS COMPLETE. Some other things have to change in order to for this approach to work. Separation of concerns among application layers and coding to interfaces across these layer boundaries must occur so that isolating code for unit testing can take place. Doing this effectively also allows developers to work without having every layer functioning – i.e. no need for a working, populated database, web services, or active directory services.

When these dependency endpoints can be ‘faked’ through some sort of abstraction (like an interface), application logic can be created and tested effectively – one test at a time. When the time comes for a true build process and deployment to an integrated, end-to-end environment, there should be fewer surprises as to how the code works when it’s all put together – all because of the effort taken to develop test first and receive feedback from the very beginning regarding how the code is behaving. See Scott Bellware’s excellent post on TDD and failing tests meaningfully for a much more elaborate discussion surrounding the benefits of good unit tests.

That’s it for now.

Oh, and for no apparent reason, here are a few more Seinfeld quotes talking about Zach’s drug problem:

PETERMAN: I'm afraid the problem with Zach is more serious. He's back on the horse, Elaine. Smack. White palace. The Chinaman's nightcap.

PETERMAN: And, in a tiny way, I almost feel responsible. I'm the one who sent him to Thailand - in search of low-cost whistles. Filled his head with pseudoerotic tales of my own Opium excursions. Plus, I have him some phone numbers of places he could score near the hotel.

PETERMAN: Damn it, Elaine. That wasn't Zach. That was the yam-yam. Now, he is going cold turkey. (Ordering) And you will be at his side.

Team Smells...Refactoring For A Better Tomorrow (Part One)

Blake Caraway — Thu, 23 Mar 2006 05:06:00 GMT

Just like any project you work on, there are signs and behaviors within a development team that indicate a need for refactoring as well. Before a development team can get to the job of developing quality code, the definition of "quality code" has to be addressed, identified, and agreed upon. I believe this is the most difficult step in evolving a development team's skill set away from the 'slap it together and fix it later' mindset. Why do I think this? Because this is exactly what I'm attempting to do with my current team.

In order to convince an entire team of developers to change the way they code, you have to establish a case for _why_ this big change has to occur. Point out where the inefficiencies in the current methods (or lack thereof) are. Make everyone realize that there is a better way. Security is a _huge_ factor because you are asking someone to step out of their comfort zone and learn something new. In fact, many take offense to this notion of improving the way they do things. This brings us to our first Team Smell:

Smell: Hubris
There are two things to consider here: 1) the industry of software development is full of bright, intelligent people, and 2) almost every person in the industry thinks they are one of these bright, intelligent beings. This is a potential team killer because the person that thinks he or she knows everything they need to know to develop good code – all too often doesn’t. I don’t want to work with someone that thinks they have nothing left to learn. This is the type of person that eschews Agile practices like TDD because he claims he can create solid, object oriented, sustainable code on his own, without some crazy process to help him along.

Refactor: This might be the most difficult symptom to battle because of the inherent human nature involved. The good part about working with someone afflicted with this condition is that they will often jump into management ;-) . Of course, you know the downside to this - they could become your manager ;-( If this smell is too widespread on a team that you are trying to change for the better, the best choice is probably to find another team and/or place to work. The point of all this improvement is to write higher quality software through better methods. If the vast majority of team members are just too full of themselves to change, then wish them the best as they continue to pump in 70-hour weeks and seek out a place where your peers will be more like-minded.

Smell: Developers Are Afraid To Modify Their Own Code
This may seem silly and unbelievable to you, but during my current project I constantly hear fellow developers say, “Yeah, but I finally got this working. If I change this now, it might break, and I just don’t have time for that”. Translation: “I have no idea how my code even compiled, much less how I would go about modifying or moving pieces of it around for the sake of refactoring, especially since the deadline is next week.” If a developer is afraid to dig into the code he or she spent a lot of time producing, chances are the code 1) sucks – in that it resembles a large plate of spaghetti – at best, and 2) has little or no chance of becoming testable without many large, risky refactorings.

Refactor: Defunkifying this smell should be easier to address because it’s simply based on a lack of understanding. Where there’s a lack of understanding, there’s usually a hidden desire to understand because the uncertainty of the work he or she is doing is somewhat unsettling. Many developers in this position simply don’t know how to shed this uncertainty. This is where preaching the value of test driven design should find an eager audience. By working in small, testable chunks, a code base evolves bit by bit, thereby reducing the chance of it becoming too large and fragile. When code is just slammed into place in order to ‘get it working’, what should have been prototype code usually becomes production code b/c the developer is just happy that the junk he or she produced compiles. All too often this type of developer knows the code should be at the very least cleaned up and modularized, much less refactored to patterns and made testable, but he or she knows the trouble they will be in when they try this – so they just let it lie.

One of the greatest bi-products of designing test-first is that when a feature is completed (i.e. all uses cases or stories are satisfied) there is a compliment of unit tests that can be run at any time to verify the code is doing the job it’s supposed to. Another great thing about code that is designed test first is the resulting structure is typically _much_ easier to 1) understand, 2) extend, and 3) if necessary, modify. I can’t start any new piece of application functionality now without beginning in a test method. I feel quite secure coding one test-case at a time, constantly thinking about the responsibilities of a class and how it should operate with its dependencies. Working in this way I know that the code was created thoughtfully and with care (as opposed to entire features crammed into 80-line methods that can do 20 things, depending on another 20 possible conditions). And thusly, when the code goes live, it will run as intended with very few surprises.

In part two, I’ll identify one or two more Team Smells and how to expunge their foul stench from your working environment.

Mine Eyes Have Seen The Glory...of TDD

Blake Caraway — Wed, 22 Feb 2006 14:16:00 GMT

I'm currently working on a smart client project at work. For the past year I've been learning about Agile software development, especially the topic and practice of Test Driven Development. This smart client project is my first real chance to put many of these newfangled ideas into action.

Seek The Green
On this project we are using the MVP pattern for the client-side development out of a desire to make the main application logic as testable as possible. With this in mind I started out my feature development trying to write targeted, intention-revealing unit tests while keeping in mind the qualities of good unit tests. As per Michael Feathers, unit tests should run fast and help localize problems. After coding a couple features on this project in test-first fashion, I can honestly say that I've become quite comfortable with the whole red-green-refactor paradigm in a very short period of time. In fact, I've begun to _live_ for an 'all green screen' when running my tests in NUnit-GUI (or when using TestDriven.Net, looking for the '0 tests failed' indicator in the Visual Studio status bar). It's very satisfying to see the test suite and code base build-up rapidly using this process.

Revelations
The two coolest things about TDD that I've seen thus far is 1) the high quality of the code that comes from following the process and 2) the way code is documented by the unit tests that cover it. I've been out of the office the past week for the birth of our second child, Grant. To help remember where I left off in my coding tasks, I was able to use the unit tests to see the work I'd accomplished (documentation). Not only that, at any given moment, to find out what my code is doing, I can take a quick look at my growing suite of unit tests (intention-revealing). The tests almost read like an outline to a short story. One other note about unit tests serving as documentation...when Microsoft released its Composite UI Application Block (CAB) back in December, I pulled down the source code and sample projects. I tried looking into the code and immediately noticed this was a very large framework for building complex smart client applications and really didn't know where to start. I noticed there both Team System and NUnit test projects included in the download, so I was able to start there and get a better idea about all the 'moving parts' of the system. I kept this in mind as I began writing my own unit tests. Although, I must say, my resulting unit tests seem to be better at revealing the intention of the code than those test fixtures provided with Microsoft's CAB.

Schedule Trumps Process...and Quality
Given the typically aggressive project schedule we usually work with (against?), the other developers on this project never really tried writing tests first to guide their work, despite us spending a not-so-modest amount of time the first week of development in large-scale XP sessions (about 5 of us in a room following along using a laptop/projector combo and rotating drivers) where we as a development team stepped through a couple use cases and began writing production code in a test-first manner (the subject of introducing a team to the practice of TDD - and the challenges involved - will be covered in a future post). Instead, they dove right in writing code as usual. Many times over the past few weeks I've attempted to look at the features the other developers have been working on, but have found that the absence of unit tests makes this task very difficult. I mean, I know the general plot of a particular feature, but to see how the code is working I have to follow method after method thru the code and maybe even debug to get a solid understanding.

No Going Back
Developing code 'the old way' - i.e. creating legacy code with every keystroke that doesn't lead to a good unit test - seems so very wrong all of a sudden. I feel like I'm more focused when designing/coding test-first. There's less of a chance of 'going off the reservation' and allowing myself to digress and write code for other features as the solutions pop into my head before fully completing the task at hand. TDD keeps me more honest and that's a good thing.

That's enough for now. Hopefully this will help offer encouragement for anyone looking to break into TDD. I know I was somewhat skeptical when I first tried writing code in a test first manner. I'm obviously still learning, but now that I have seen the process and how quickly it proves its worth (I'll discuss this more in a future post, as well), I've seen the light. Those individuals that remain skeptical of TDD - and Agile software development in general - call this shift in thinking 'drinking the KoolAid' - at least the developers/managers I work with on a daily basis do. It's a not-so-subtle reference to buying in wholesale to a movement or new way of thinking and more or less becoming a zealot to a cause on faith alone. I have more thoughts on why developers/managers react in this way, but yep, you guessed it...I'll save it for another post. Call it whatever you want. If I'm 'drinking the KoolAid', then I guess my preferred color of said sugary beverage is NUnit Green.