• Bill Nicolich (7/2/2009)


    Solomon suggests that unit testing doesn't deal with performance features. Is this a universally-understood rule? Thank you.

    Hey there, Bill. I guess you ultimately want someone else to answer that question since I will only confirm what I said ;-), but I can add to it first.

    It seems that there is a general misunderstanding in the DB world of what Unit Testing is. Unit Testing is supposed to test a very specific piece of functionality. Given a set of inputs and outputs it can be determined whether or not a particular set of logic is working as expected. This is irrespective of how quickly and/or efficiently it works. It is just functional testing on a particular method / function / procedure.

    A further complication is that true Unit Testing tests ONLY that piece of logic regardless of any external dependancies that piece of logic might have. For instance, when doing Unit Testing of a C# method, if that method makes a DB call or a call to another method, those external calls are "mocked" with given return values so that the piece of logic being Unit Tested is truly isolated. There is no way (that I know of) to "mock" external calls within a Stored Procedure. So if you test a Stored Proc that calls another Stored Proc or a User-Defined Function, then you are not doing true Unit Testing since you will really be testing the Proc you intended to test plus anything it calls. And even if you could "mock" external Proc or Function calls, what would you do in the case of a Trigger. And the issue of whether or not data constitutes an external dependancy is another story, but maybe not as important because it can be, to a degree, isolated within the scope of a transaction.

    So in the DB realm we do functional testing (that sometimes people call Unit Testing) the best we can. And again this is why I like DbFit: it facilities easy, and repeatable / automated testing without requiring any updates to the DB for testing. You do not need to add any testing procs to the DB in order to test. This also makes the tests very portable since you can simply change connection strings and not have to worry about "deploying" test procs and keeping those up to date in each environment & server.

    Take care,

    Solomon...

    SQL#https://SQLsharp.com/ ( SQLCLR library ofover 340 Functions and Procedures)
    Sql Quantum Lifthttps://SqlQuantumLift.com/ ( company )
    Sql Quantum Leaphttps://SqlQuantumLeap.com/ ( blog )
    Info sitesCollations     •     Module Signing     •     SQLCLR