A co-worker overheard the comment that "agile [software development] is not always a good fit for introverts," or something along those lines, while listening to a webinar on agile testing. On the surface, it is hard to deny that claim. Right there in the Agile Manifesto we have two obvious yellow or even red flags:

• Individuals and interactions, and
• Customer collaboration

Now jumping over to the Principles, we find two more orange flags:

• Business people and developers must work together daily throughout the project.
• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Sometimes you need to go back to the basics - including basic technology. In this case, I mean sticky notes. Yes, they are a remarkable form of technology. I like doing everything the digital way. I abhor using paper when not necessary, because of the waste factor. Although I love the idea of note cards for user story development, I've been thankful that they are impractical for my development team. But, I think it is time to heed good advice.

We build a lot of console applications, and Windows services, that process inbound and outbound files in one way or another. Most depend on configuration data and some load (or unload) business data from a database, in addition to accessing the files. Testing these has always been a chore, to say the least: configurations change, data are deleted, and there's never enough time. After building a few rudimentary tools that have helped, necessity, and Agile Testing: A Practical Guide for Testers and Agile Teams, has convinced me that it is time to get serious about system/integration test automation, just as I did about unit test automation a few years ago. This is the first of a n-part series of posts on this process

Problem: using Application Settings in a .Net project, you find that there are so many entries that some organization is needed.

Solution: create custom, serializable data types for logical groups of settings.

Problem: need to move rows up and down, and from one table to another, in an HTML page.

Solution: careful use of jQuery. There are probably many different solutions already out there, but I wanted to learn how to write one for myself. Key functions: closest, detach, append, prev, next, before, and after.

Wherein I record a few tips on the use of System.ComponentModel.DataAnnotations, which I am likely to forget if I do not need to think about them again for some months…

Growing Object-Oriented Software, Guided by Tests by Steve Freeman and Nat Pryce

I did not realize how much I still have to learn about writing good object-oriented (OO) code, and about hewing to a tight test driven development (TDD) methodology, before I read Growing Object-Oriented Software, Guided By Tests. My education in OO and unit testing has been largely theoretical, with no time spent directly learning from experienced OO programmers; my best mentor was a COBOL coder. Books like Design Patterns: Elements of Reusable Object-Oriented Software, Patterns of Enterprise Application Architecture, Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, Xunit Test Patterns: Refactoring Test Code, and others are wonderful but have few detailed real-world business-case examples.

Test driven development is hard. Perhaps it would not be if we were taught to think about OO development from a TDD perspective in the first place; but those muscles are poorly developed, and the exercise leaves you sore and panting a bit. As with physical exercise, there is a reward in the pain. Perhaps others do not see it, but I can already see the benefits accruing in Reggie as I rebuild it with SOLID principles in mind, driven by tests. To help me consolidate where I’m going, and help others whose TDD muscles are likewise under-developed, let us walk through a test, shall we?

Moles is a powerful and useful framework for unit testing. Or was. But even then, it was overused (at least by me). But no more!

Reggie, my regular expression testing application, has been rebuilt in the Caliburn Micro framework, using Ninject for Inversion of Control and MoQ to round out the unit tests.

Now that I've learned something about WPF, and that "out of the box" it is not entirely trivial to work with, it seemed worthwhile to rebuild the app using a standard framework, viz Caliburn Micro. The Mindscape Blog offers a friendlier CM tutorial than the one on the project's website.

In addition, I simplified the architecture by removing the separate business layer. The business logic is so light that it is not worth the effort (20 lines!). I will refactor if doing so provides a real benefit.