I have just got back from SQLBits after giving my session on Unit testing in SQL. As I said at the start of my session, at developer events I often feel a bit of an outsider when I say I am talking on testing as opposed to development; today it was doubly so when surround by so many DBAs. I have to say some of the sessions I attended seemed to be from a completely different world to my day to day work. Hey but that is what makes IT interesting is it not?
I think the event went really well and I would like to thank the organizing committee for all their work getting the event going and thanks to everyone who filled my session to bursting. I was surprised how much interest it generated and how well it seemed to be received.
For those who are interested, my slides can be found at http://www.blackmarble.co.uk/ConferencePapers/SQLBits - Unit testing in SQL.ppt.
The one point that was left unanswered from my session was that of deployment of changes to a DB from DataDude. The answer is that the build option in DataDude generates a change SQL script (in the SQL sub directory under the project folder). The deploy option runs this script against the local copy of the DB on the development PC as defined in the project properties. The point I forgot during the session was that this working development copy of the DB is not the same as the one I imported schema from, hence we could not see the changes in the original DB because this was not the DB the script was run on. In most cases you use this generated script to update a live database via a manual release or separate automated process. Hope this clears up any confusion.
I look forward to hearing everyone's feedback on the event