Click here to monitor SSC
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


DBFit best practices?


DBFit best practices?

Author
Message
DonaldW
DonaldW
Ten Centuries
Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)

Group: General Forum Members
Points: 1312 Visits: 487
I recently read Solomon Rutzky's article on DBFit (http://www.sqlservercentral.com/articles/Testing/64636/) and I've been working with it. Once I get past a few of the gotchas such as needing to use True\False in the DBFit code where SQL Server expects 0\1 for bit values it's a nice tool.

I was wondering if there are best practices for use of the tool or even for automated database testing in general? For example, the article talks about creating objects (tables, procs, etc) on the fly so they can be rolled back. That's a great concept but I'm running into problems implementing it. For example, I comment my procs so I can remember just what the heck I was doing but double dashes won't work when creating the proc from DBFit.

The simple answer is to take out comments and such in the DBFit html but then you are testing something other than what you wrote or will put into production. Also, you have to make updates in DBFit when you update your scripts, etc. Too much room for error in either screwing up a copy\paste or forgetting to copy in the change.

I'm considering maintaining the database by running the scripts using SQLCMD Mode from SSMS then handing over the DBFit html to the testers. That separates the database maintenance from the testing while still being able to build the database to a known state. The maintenance scripts and testing html would be stored in the same place in source control and checked out all at once when needed.

Does anyone have any words of wisdom on the subject?

Thanks.

Don



Solomon Rutzky
Solomon Rutzky
Say Hey Kid
Say Hey Kid (662 reputation)Say Hey Kid (662 reputation)Say Hey Kid (662 reputation)Say Hey Kid (662 reputation)Say Hey Kid (662 reputation)Say Hey Kid (662 reputation)Say Hey Kid (662 reputation)Say Hey Kid (662 reputation)

Group: General Forum Members
Points: 662 Visits: 2937
DonaldW (4/28/2011)
I recently read Solomon Rutzky's article on DBFit (http://www.sqlservercentral.com/articles/Testing/64636/) and I've been working with it. Once I get past a few of the gotchas such as needing to use True\False in the DBFit code where SQL Server expects 0\1 for bit values it's a nice tool.

I was wondering if there are best practices for use of the tool or even for automated database testing in general? For example, the article talks about creating objects (tables, procs, etc) on the fly so they can be rolled back. That's a great concept but I'm running into problems implementing it. For example, I comment my procs so I can remember just what the heck I was doing but double dashes won't work when creating the proc from DBFit.

I'm considering maintaining the database by running the scripts using SQLCMD Mode from SSMS then handing over the DBFit html to the testers. That separates the database maintenance from the testing while still being able to build the database to a known state. The maintenance scripts and testing html would be stored in the same place in source control and checked out all at once when needed.


Hey Don. I am glad that you found the DbFit article helpful. :-)

First off, I would suggest that you check out the Google Group for DbFit at: http://groups.google.com/group/dbfit

Regarding comments in the SQL within an Execute block, I noted in the article that "you cannot use inline (--) comments in block SQL code, but you can use block comments (/* ... */)". Hopefully using block comments is acceptable.

Regarding the temporary objects noted in the article examples, that was just to show a simple and self-contained example. I do not recommend creating the objects you want to test within the DbFit tests themselves. The beauty of DbFit is that you don't need to alter your environment at all with the testing apparatus. This leaves a clean testing environment that mirrors production and provides a more trustworthy test. The only objects that should be created within a DbFit test are ones that are specifically for testing and are not part of your application.

I believe DbFit also provides a way to fully automate the testing so that you can have a CMD script that first calls SQLCMD to push the changes to your QA environment and then DbFit to test them.

We use DbFit a lot where I work and we set up a "Suite" that contains other "Suites" which contain the "Tests". This way we can logically separate the functionality to test by either doing a specific "Test", a specific "Suite", or all "Suites" by selecting the top-level "Suite". We also put our connection strings and other global variables in the Setup page so that they can be reused easily.

I hope this helps. Take care,
Solomon...

SQL# - http://www.SQLsharp.com/
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search