XUnit Test Patterns : Refactoring Test Code
Today I came across something rather interesting when I went to amazon.com to buy Refactoring Databases. Looks like a very interesting book that would be quite valuable … at the moment my team is currently facing some issues around testing, such as tests taking too long (we currently have 1100 test cases that run), as well as the case of mysteriously breaking tests (sometimes it workes, sometimes it doesn’t, or it doesn’t when database connectivity is down).
So, I was about to order it when I noticed it’s not availble yet. Saddened, I did a quick search and came across the xunit patterns site which contains much of the material that will make it’s way into the book. And browsing through the site, I must say I feel compelled to go ahead and preorder the book! So much good stuff on there that I don’t know where to start! 
Of particular interest to me is the fixture patterns. We use fitnesse alot at work for acceptence testing, and my team and I are constantly searching for ways to improve our tests (as most of our existing ones are ad hoc and quickly written tests). The Automated Teardown fixture pattern is one that I have already seen in one of my current tests … simply look up the data in the database I knew would be affected, persisted it, then run the process, check results, and then restore the data to it’s original state. And, sadly, I have seen more than my share of the smells, especially in some of my tests.
While I’m on the subject of tests, there’s been a lot of good noise in the blogsphere (and the extremeprogramming mailing list) about test automation, with plenty of good ideas and comments thrown around. I kind of like how Ron sums it up:
if we want to be excellent at automated testing, we should set out to automate all tests. We’ll probably never get there, but we might get the Silver and Gold along the way.
If you're new here, you may want to subscribe to my RSS feed. Thanks for visiting!
