This past weekend I attended the Alberta TechFest (an event put on by Calgary .Net User Group). TechFest resembled a code camp, but provides more seminars / sessions geared at a higher level. The sessions were geared towards: project management, the big picture of the Agile process, open source alternatives, as well as some in depth (show me the code type) presentations on Mock objects (using Rhino Mocks), Microsoft’s new Acropolis framework, Test Driven Development (TDD), and Refactoring.

My highlights:

• The session on Agile Project Planning With User Stories, and Refactoring Automated Unit Tests Using Test Smells and Patterns presented by Gerard Meszaros. I’ve been on a couple projects that could be characterized as “Bad Agile”, so Gerard’s presentation hit many chords, one of the comments he made really stuck out. He said something like: “it’s not about the Agile process, it’s about the results, it’s about delivering…don't be dogmatic”. Sure it’s obvious, but it’s nice to hear it from someone else.  I’m currently in the process of purchasing Gerard’s book: xUnit Test Patterns: Refactoring Test Code.
• Mock objects  with Rhino Mocks was another great session, the presenter Shane Courtrille is a Rhino Mock ninja. I’ve been using Rhino Mocks for a couple months now, but there’s always so much to learn from someone with more experience.

I’m trying to make it a point to attend more of these events in an effort to expand my community.

The quality assurance (QA) activities in software development generally include: defect tracking, Unit Testing, source-code tracing, technical reviews, integration testing, and system testing. Out of these activities: Unit Testing, source-code tracing, and integration testing are informally left to the developer. Out of these three developer specific activities, Unit Testing seems to be the most overlooked and misunderstood activity with the greatest potential for improving the development process (improving quality, efficiency, etc...).

The procedure [for Unit Testing] is to write test cases for all functions and methods so that whenever a change causes a regression, it can be quickly identified and fixed. - Wikipedia: Unit_testing

By writing good unit tests and employing a good Unit Testing framework you can significantly improve your software development cycle. By writing unit tests you decrease your dependency on a debugger, decrease source-code tracing (debugger walkthroughs), and so on. And by employing a good Unit Testing framework you can begin to lay the scaffolding for other forms of developer specific testing (integration, system testing, and even GUI testing). Unit Testing also contributes to better documentation - if a developer doesn’t understand the purpose of a component they can now read an additional piece of documentation, the unit tests. Unit Testing and Unit Testing frameworks can bring a team of developers to the same level - the capabilities within a team vary by developer. By using the same underlying framework, by identifying general areas that always need Unit Testing we develop a heuristic approach to testing and with that, test patterns, and a new vocabulary to assist with inter developer communication - design patterns accomplish a similar goal. Marc Clifton has a tutorial on Unit Test Patterns.
Unit Testing has its flaws just like any other technique or methodology - there are no silver bullets. Unit Testing is contingent on GOOD unit tests - it’s just as easy to write bad code that works, as it is to write bad unit tests that pass (work). Unit Testing won’t catch every error, but that’s the reality of writing programs, it’s also why we have a large number of software testing (QA) activities - writing software that is 100% bug free is impossible. These are just a couple issues with Unit Testing.

[Test-Driven Development is] a computer programming technique that involves repeatedly first writing a test case and then implementing only the code necessary to pass the test. The goal of test-driven development is to achieve rapid feedback. - Wikipedia: Test-Driven Development

The Test-Driven Development (TDD) programming technique is fundamental to many of the Agile methodologies - particularly the Extreme Programming (XP) methodology. The TDD approach uses Unit Testing as a process for designing and testing software. The core idea behind TDD is to have the developer "write the test first" then write the code to pass the test. The technique forces the developer to "thinking before acting" which is really a "best practice" advisable for everyone - I would hope that "thinking before acting" is practiced informally by most experienced developers, but that's often not the reality. Other programming techniques that revolve around the "thinking before acting" idea include: the Pseudocode Programming Process (PPP), and the Program Design Language (PDL) Both the PPP and the PDL have gained exposure through Steve McConnell's book Code Complete.

The mature unit testing frameworks that have gained popularity through the TDD / XP community are important; unit testing through these frameworks will compliment any quality assurance plan and improve any development process.

For more information on Unit Testing and TDD see the following:

ScottD's Musings: My Uber-Test-Driven Development ("TDD") Links Listing
Introduction to Test Driven Development (TDD)
Wikipedia: Test-Driven Development
Wikipedia: Unit Testing
Marc Clifton's Advanced Unit Testing Tutorials (See my previous post: Advanced Unit Testing: NUnit)
Kent Beck: Test Driven Development: By Example (a great book)
Construx: Developer Testing Boot Camp (a course)

Marc Clifton has a great five part series on Advance Unit Testing. Throughout these articles Marc builds a Unit Testing framework based on the NUnit framework - NUnit is a Unit Testing framework for Microsoft .NET, it's very similar to the JUnit framework for Java. Marc explores Unit Testing, the interworkings of Unit Testing frameworks, and the XP methodology.
Don’t be intimidated by the number or size of these articles - most of the content is source code.

Part I: Introduction to unit testing and a case study taking the XP process up to the point of writing some unit tests
Part II: Implementation of an NUnit look-alike and developing the case study further with real tests and real code
Part III: Implementation of NUnit extensions, revising and progressing with the case study
Part IV: Using reflection to create unit tests that are script based instead of code based, and the impact of that on the case study
Part V: Unit Test Patterns

On a related thread:

Learn more about Test-Driving Development (TDD) on Wikipedia.
Learn more about NUnit at http://www.nunit.org/.