What is the best way to test a stored procedure?

Question

Like many companies that require all access be through stored procedures, we seem to have a lot of business logic locked away in sprocs. These things are just plain hard to tes

Answer 1

Here's my low-tech, quickie method of just keeping example inputs conveniently located in the DDL

USE [SpacelySprockets]

GO

/****** Object:  StoredProcedure [dbo].[uspBrownNoseMrSpacely]    Script Date: 02/03/3000 00:24:41 ******/

SET ANSI_NULLS ON

GO

SET QUOTED_IDENTIFIER ON

GO

--================================

--Stored Procedure DDL:

--================================

--Example Inputs

/*

DECLARE @SuckupPloyId              int

DECLARE @SuckupIdentityRecordId        int 

SET        @SuckupPloyId               = 3

*/

-- =============================================

-- Author:     6eorge Jetson

-- Create date: 01/02/3000

-- Description:    Sucks up to the boss

-- =============================================

CREATE PROCEDURE [dbo].[uspBrownNoseMrSpacely]

    @SuckupPloyId              int

   ,@SuckupIdentityRecordId    int OUTPUT 

AS

BEGIN
    DECLARE @EmployeeId     int
    DECLARE @SuckupPoints   int
    DECLARE @DateTimeStamp  datetime

    SET     @EmployeeId     = dbo.svfGetEmployeeId('6eorge Jetson')
    SET     @SuckupPoints   = dbo.svfGetSuckupPoints(@SuckupPloyId)
    SET     @DateTimeStamp  = getdate()

    --Data state-changing statement in sproc
    INSERT INTO [dbo].[tblSuckupPointsEarned]([EmployeeId], [SuckupPoints], [DateTimeStamp] )
    VALUES (@EmployeeId, @SuckupPoints, @DateTimeStamp)

    SET @SuckupIdentityRecordId = @@Identity
END

--Unit Test Evidence Display
/*
SELECT
     @EmployeeId    as EmployeeId
    ,@SuckupPoints  as SuckupPoints
    ,@DateTimeStamp as DateTimeStamp
*/


--==========================================================================
--After editing for low-tech, non-state changing "unit-like" test invocation
--==========================================================================

--Example Inputs
DECLARE @SuckupPloyId               int
DECLARE @SuckupIdentityRecordId     int 
SET     @SuckupPloyId               = 3

/*
-- =============================================
-- Author:      6eorge Jetson
-- Create date: 01/02/3000
-- Description: Sucks up to the boss
-- =============================================
CREATE PROCEDURE [dbo].[uspBrownNoseMrSpacely]
     @SuckupPloyId              int
    ,@SuckupIdentityRecordId    int OUTPUT 
AS
BEGIN
*/
    DECLARE @EmployeeId     int
    DECLARE @SuckupPoints   int
    DECLARE @DateTimeStamp  datetime

    SET     @EmployeeId     = dbo.svfGetEmployeeId('6eorge Jetson')
    SET     @SuckupPoints   = dbo.svfGetSuckupPoints(@SuckupPloyId)
    SET     @DateTimeStamp  = getdate()

    --Data state-changing statement now commented out to prevent data state change
--  INSERT INTO [dbo].[tblSuckupPointsEarned]([EmployeeId], [SuckupPoints], [DateTimeStamp] )
--    VALUES (@EmployeeId, @SuckupPoints, @DateTimeStamp)

    SET @SuckupIdentityRecordId = @@Identity

--END   --Need to comment out the sproc "END" also

--Unit Test Evidence Display
SELECT
     @EmployeeId    as EmployeeId
    ,@SuckupPoints  as SuckupPoints
    ,@DateTimeStamp as DateTimeStamp

It works even better for udfs as there is no change of state to worry about. Clearly, I wouldn't recommend this in lieu of a testing framework, but if I stick to this simple seconds-costing discipline of

Assert that my managable-sized sproc passes at least a simple "unit test"

prior to executing CREATE PROCEDURE, I find that I make fewer mistakes (likely due to discipline more than the test itself).