SqlTdd : Configurable Transaction Rollback Teardown

Posted by indomitablehef | Filed under SqlTdd

I’ve added a new feature to SqlTdd, configurable transaction rollback teardown. By default, all tests in the TestCatalog use transaction rollback teardown, but you can decorate a test with UseTransactionRollbackTeardown = 0, to tell the SqlTdd framework to run that particular test without it. This property is set when you Mark the test procedure for discovery, using the [SqlTdd.Util].MarkTestMethod procedure.

I plan to tackle Test Suite Setup and Teardown next.

SqlTdd 0.1 Released

Posted by indomitablehef | Filed under SqlTdd

SqlTdd 0.1 is now available at http://code.google.com/p/sqltdd. More features are on their way. I’d very much appreciate feedback on it.

The Motivation Behind SqlTdd

Posted by indomitablehef | Filed under SqlTdd, TDD

We software developers have a tendency to turn our noses up at SQL “code”. When we get excited about good design, good sql design is rarely part of the discussion. Likewise, when we talk about Testability, the goal is often to eliminate the database from what we’re testing entirely. I’m all for that, actually, but it’s not the whole story. The reality is that SQL Stored Procedures, functions, and other programming constructs is often the “right place” to implement some piece of functionality. Even when the argument can be made that it’s not, sometimes that’s where it ends up anyway. Sometimes, that’s the skillset you have available, so that what you do. It’s “the hammer” antipattern:

When all you have is a hammer, everything looks like a nail.

But calling it an anti-pattern isn’t enough. There’s a lot of working code out there, written entirely in SQL. There are a lot of capable SQL developers out there, and they’re mostly being ignored by the part of the industry that cares about testabilty, agility, and refactoring.

SqlTdd isn’t the first unit testing framework for SQL Server, but it’s my attempt to build a better one. Here are some of my design goals

1. A capable SQL devloper should be able to use it without ever needing to leave SQL Server Management Studio - i.e., entirely in SQL, as far as he’s concerned
2. It should lend itself well to the use of “Tests as Documentation”, and generally more readable SQL Code
3. It should integrate well with existing automated build and continuous integration tools used in traditional Test Driven Development
4. It should enable sophisticated testing techniques, such as custom assertions, transaction rollback teardown, Test Suites, setup/teardown, and even mocks and stubs.

SqlTdd 0.1 to drop on Monday

Posted by indomitablehef | Filed under SqlTdd

SqlTdd is a unit testing framework for SqlServer 2005/2008, and I’m working hard to get it ready to post on google code on Monday. Stay tuned.

The Will to Change

Posted by indomitablehef | Filed under Refactoring

It’s that time of year, again: when I start writing down goals and trying to plan for the year to come. One of my professional goals this year is to be more “community oriented”. For me, that means blogging, being involved with local developer groups (like Nashville Alt.Net and the Geek Social, to start), and OSS. I’m planning to release my SQL TDD framework very soon, and hoping to contribute to at least one other Open Source project during the coming year. So, if all goes well, you should start seeing more posts from me here in the future, starting now.

Then he showed these men of will what will really was. - Kaiser Soze

Awhile back, I read Ayende’s post on Reducing The Cost Of Change. It made a huge impression on me, and has changed the way I look at refactoring and change ever since.

The gist of it is this: We have all kinds of tools and practices designed to reduce the cost of change: TDD, Iterative Development, the Single Responsibility Principle…and the list goes on and on and on. Embracing Agile, we embrace the idea that change is inevitable, and we do our best to make it as painless as possible in everything we do along the way.

But when it comes time to change, there’s no substitute for the will to change:

But it is neither the tools nor the practices that actually enable change. They are not even significantly responsible for reducing the cost of change. Beyond anything else, it is the will of the team to accept the pain of making the change and actually doing this.

How many times have I avoided making a change because it seemed to painful, too difficult? And how many of those cases do I look back on and see that when I finally did make the change, it turned out not to be such a big deal after all? Even when it was a big deal, the worst part of the experience was usually the anticipation and and dread I experienced leading up to the change, rather than the change itself.

When you take this to heart, it can change the way you approach things from the very start, as I am beginning to see. You develop the courage to simply try things, knowing that you will have the will to change it later on.
Quoting Ayende again:

That mindset, at least for me, starts from the first line of code. I treat each piece of the project as utterly disposable. Since I don’t really care how each individual piece works, I am able to roughly sketch a fair amount of the application very rapidly, and then focus on each of the items in isolation, and replace that with a much better implementation. I think that I stated before that I tend to rewrite most of my application core at least two or three times before I am happy with them.

So thanks, Ayende. This short little post has been an “ah-hah!” moment for me, and I think I’ll always be a better developer because of it.

Fluent NHibernate

Posted by indomitablehef | Filed under NHibernate, ORM

I started playing around with Fluent NHibernate today. What a fantastic improvement over the old .hbm (xml) file configuration! Details here.