I'm not a .Net guy either... that's why I just right click on a proc in QA and select [OPEN].  A windows opens with all the parameters available which can be filled in.  When you finally select execute, it opens a new query window with the code the system wrote to do the test. 

Not sure if we're talking the same thing, though...

I like the idea of formal unit testing, although I'm yet to be convinced that it's something that many database devleopers have seriously tried to adopt, although this could be because there are not enough tools like DBPro and TSQLUnit that provide an easy-to-use framework from which tests can be authored and run.

I'm curious know how DBPro unit testing compares to TSQLUnit? Are there pros and cons to their respective approaches?

David

I've used both (and wrote articles on both). I think the TSQLUnit is a more pure version of unit testing than DBPro. TSQLUnit also has pretty good reporting capabilities on the results of multiple tests.

DBPro is a lot easier to use and more easily extended than TSQLUnit. Then there's the convenience factor. As someone noted above, right click on a proc and you've got a unit test with parameters built in. Too easy.

I don't know that we'll write formal unit tests for all our procs, but we know that some apps or some procs within apps are candidates for frequent tweaks during development. So, those we get tests for. They've proved invaluable. I just recently rewrote a series of procs from an old project. I created tests for procedure with a before & after run through the data compare extension. I was able to validate these procedures as I went which convinced the business unit that I wasn't ruining their lives but rather improving them.

Hi,

I have implemented the code pretty much as written, but am having trouble getting the test condition registered. 

Your article does not describe how to add the assembly to the GAC, or to generate the public key that you have in the xml, but I found this info in Sachin's original article.  It would be helpful to see this info in your article, as well as a suggestion for how to name your project at the start.

I do think that you mistyped the line

<extension type="TablesEqual.TablesEqual" enabled="true" />

in your xml file: Assuming that you named your assembly TablesEqual, shouldn't you use TablesEqual.DataEqual?

There is also a disagreement between your article and Sachin's about where to put the xml file.  He says the DBPro directory, you say the MSVSTEDB - ENU directory.

On to my problem - I have the code compiled into a DLL.  I have run gacutil and have copied the public key into the xml file.  I've put the xml file in both directories suggested above, and still have no luck in getting the condition to show up in my tests.  I've tried creating new test projects and also tried manually adding my dll as a reference for the test project.  None of this seems to work.

Any suggestions?

Mark

I think you're correct on my errors in the article. Thanks for the input. I'm not sure if Steve will let me do an update, but I'll check.

I suspect it's the XML. Every time I've had a problem, that's been where it resided. One other issue, the code I wrote was against the CTP6 version of the software. Several small things changed with the release, especially some of the formatting for the XML file. Check the online documentation to verify what you have is the latest format.

That did it, thanks.  I found the info at

http://msdn2.microsoft.com/en-us/library/aa833231(VS.80).aspx

Some extra attributes are required on the extensions line:

<extensions assembly="CustomCondition, Version=1.0.0.0, Culture=neutral, PublicKeyToken=<enter key here>" version="1"  xmlns="urn:Microsoft.VisualStudio.TeamSystem.Data.Extensions" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:Microsoft.VisualStudio.TeamSystem.Data.Extensions
Microsoft.VisualStudio.TeamSystem.Data.Extensions.xsd">

Note the extra attributes after version="1".

So to sum up info that could improve the article

1. At the top, specify the assembly name you are creating, since it will be needed in the xml file.
2. In the code, consider adding an override of the ToString method to give a meaningful description of the test condition in the Values column of the Test Conditions list box.
3. Describe (or point to a description of) how to sign your code, run gacutil, and get the public key.
4. Update the xml example
1. Make sure the assembly name matches the assembly name created above.
2. Add the extra attributes at the end of the extensions line.
3. Clarify that extension type="<NameSpace>.<ClassName>"
4. The current directory in which to drop the xml file is c:\Program Files\Microsoft Visual Studio 8\DBPro\

Thanks again for your help, and for the article,

Mark

I was just going to look this up and I saw your response. Thanks for the assist.

I'll look into updating the article, but if I can't, at least your comments will be here to help out.

Thanks again.