- Posted by ian suttle on June 14, 2008
- Filed under Agile | Process | Unit Testing
Here Ye! Here Ye!
Welcome to post number two in our ongoing journey to bring an effective agile development process to IGN Entertainment.
There are a few staple tools and practices I feel are essential to an effective agile development process. Some may argue the direct correlation of these to agile development is incorrect... it's perspective.
Source Control
Love it or hate it source control is a biggie. There are a variety of source control systems available to meet the needs of most organizations. A few popular choices include Subversion, Visual SourceSafe, CVS, Team Foundation Server, and Perforce.
I recommend figuring out your source control feature requirements before choosing your flavor. Try a few before committing. Not all of them do branching, merging, changesets, etc, in the same fashion, and once you implement one it's likely not convenient to migrate to another.
Define your source control structure and processes for the team. Should code be organized by library type such as web apps, windows service, class libraries... or should it be organized by subject such as Direct2Drive, Fileplanet, etc? When should you branch vs. label? How do you version your software? If you forgo being organized up front you will pay the price later. For those of you who choose the hard way, it provides you the unique opportunity to write about lessons you've learned later on ;).
Unit Testing
I've been a part of the development community for about ten years now and if there's anything I've picked up on over the past couple of years unit testing is a contender for the most valuable. For those of you who are rookies on the topic or still haven't quite figured out what the hype's about, listen up. Unit testing provides you a certain level of confidence in your code both when you write the code and when you change your code.
Consider a monitor watching a website. Some monitors will watch the site and ensure expected behavior occurs given specific criteria. In this way a unit test is a lot like that monitor. You set up a very specific well-controlled scenario for a unit of your code (see method) and fail the check if the result isn't as expected. Each time you change your code you can rerun your ever-growing library of unit tests and be assured your tests continue to succeed. If a test is busted ya screwed something up. Oh, and as an added benefit, your class design changes to be more modular. That's just a little something extra.
Unit tests frameworks come in a variety of shiny colors. For .NET development NUnit is probably the most used. You can also check out XUnit and MbUnit. Lastly, Microsoft has developed their own framework which they've integrated in to VS2008. Feel free to argue your points but I'm not a fan of the MS Unit Test framework... there's too much auto-generated code for me. The point of unit testing is to know and control your environment. Code generation tastes bad.
TestDriven.Net is a cool add-on to Visual Studio so you can run your NUnit tests (I've not tried with another framework) and get your results in the Output window. It also comes bundled with NCover for code coverage analysis. Really useful.
Drink the kool-aid... it's yummy.
Continuous Integration
Continuous Integration in its most basic form is having your code built often on a scheduled or triggered basis. This is cool because you can know earlier than later if someone's changes are breaking the build (don't be that guy!). The alternative is having a broken build and when you have more than one person working on the code all participants are effected once they have the latest version. That's a waste of time for everyone and is frustrating to say the least. Continuous Integration doesn't prevent this problem but instead is an early warning system. Now add on automated deployments to an environment such as user acceptance testing and there's constantly a fresh view of the application without an engineering making it happen. That's cool.
My team is not using a Continuous Integration solution yet so more to come on this, but if interested, we're checking out Team Foundation Build and JetBrain's TeamCity.
How's This Related to Agile Development?
Admittedly you can run an agile development shop without any of these tools. These things I've discussed are just that... tools, not process. So how are these tools related to agile development? Everything I've discussed works really well with the iterative, always changing nature of agile practices. I'd hate to take on this process unprepared. Give me my armor, sword, and a horse before sending me off in to battle.