Skip to content

SpyProcedure fails when paired with a RemoveObject #198

Open

Description

@vkuharsky

I have a test where I need to mock a bunch of validation SPs and also want to replace one SP with a mock that should just throw an arbitrary exception to imitate SQL error during code execution. Everything was looking fine until that test case was executed.

After some code tweaks inside the test itself, I've found that after the actual code execution of the tested procedure _SpyProcedureLog table for my mock magically disappeared and is no longer available for the later portion of the test.

Here is an example code that illustrates what is going on inside the described test case:

CREATE PROC TestClass.[test application locks]
AS
-- Faking a dozen tables by using tSQLt.FakeTable
-- Faking a dozen small SProcs using tSQLt.SpyProcedure

EXEC tSQLt.SpyProcedure 'dbo.Entity_Lock';
EXEC tSQLt.SpyProcedure 'dbo.Entity_Release';

-- Replacing an object of interest by using a documented approach
EXEC tSQLt.RemoveObject 'dbo.usp_NeedToThrow';
EXEC('CREATE PROC dbo.usp_NeedToThrow AS RAISERROR(''This is a test'', 16, 1);');


EXEC tSQLt.ExpectException @ExpectMessage = 'This is a test';
-- Running my SP
EXEC dbo.usp_TestMePlease 'Param1', 'Param2';

-- Asserting the results 
IF NOT EXISTS ( SELECT 1
                FROM dbo.Entity_Release_SpyProcedureLog )
    BEGIN
        EXEC tSQLt.Fail 'Release was not called properly';
    END

RETURN 0;

When I run this test without TRY CATCH BLOCK wrapping a EXEC dbo.usp_TestMePlease ...,
I'm getting an error: TestClass.[test application locks] failed: : (Error) Message: Cannot release the application lock (Database Principal: 'public', Resource: 'Resource.NameIt') because it is not currently held. | Procedure: xp_userlock (1) | Severity, State: 16, 1 | Number: 1223 (There was also a ROLLBACK ERROR --> Message: The ROLLBACK TRANSACTION request has no corresponding BEGIN TRANSACTION. | Procedure: Private_RunTest_TestExecution (154) | Severity, State: 16, 1 | Number: 3903)
That message obviously shows that the actual code uses the non-mocked version of dbo.Entity_Release. This clue was confirmed a bit later when I ran my SP within the TRY ... CATCH block. Then the test failed with another error: (Error) Message: Invalid object name 'dbo.Entity_Release_SpyProcedureLog'

SQL Server version: 12.0.2269.0 (MS SQL Server 2014 Express Edition)
tSQLt version: 1.0.8083.3529

Activity

  1. mbt1 commented on Feb 27, 2024

    @mbt1
    Collaborator

    Is it possible that the procedure under test issues a rollback, explicitly it implicitly?

  2. vkuharsky commented on Feb 28, 2024

    @vkuharsky
    Author

    Yes, you're right.
    Inside of the tested procedure, I do rollback in case of error.
    Here is an example structure of how I do that:

    CREATE PROC dbo.usp_TestMePlease @Param1 INT, @Param2 INT
    AS
        SET NOCOUNT,
            XACT_ABORT ON;
    -- Skip other parts of a prolog
    -- ...
    EXEC dbo.Entity_Lock;
    BEGIN TRY
    -- Do some pre-data writing checks
    -- ...
    BEGIN TRANSACTION
    -- Do data modifications
    COMMIT TRANSACTION
    EXEC dbo.Entity_Release;
    END TRY
    BEGIN CATCH
    IF @@TRANCOUNT > 0
        BEGIN
            ROLLBACK TRANSACTION;
        END
      EXEC dbo.Entity_Release;
      THROW;
    END CATCH
    
    RETURN 0;
  3. vkuharsky commented on Feb 28, 2024

    @vkuharsky
    Author

    After tinkering a bit longer, I've managed to make this test passable. The problem, though, is obvious. While semantically correct, the code above is not intended to be run inside another (outer) transaction. I designed this code to be a top-level data API consumable only by external clients, such as services hosting applications. 

    Is it possible to make such tests passable without changing how the code works with transactions?

  4. mbt1 commented on Feb 28, 2024

    @mbt1
    Collaborator

    There are two possible solutions. The one is similar to what you have done. Change the procedure to use a transaction save-point in your procedure. I wrote about that a while ago here: https://sqlity.net/en/585/how-to-rollback-in-procedures/
    This preserves your intended functionality without colliding with pre-existing transactions.

    The technique above is the preferred architectural solution, because it solves other problems that you might run into, too. But if that change is not possible, there is the other solution. It is an advanced tSQLt technique that runs the test without initiating a transaction. This is fairly new functionality in tSQLt and not yet well documented. I'll attempt to write something up this weekend.

  5. vkuharsky commented on Mar 5, 2024

    @vkuharsky
    Author

    I'm very interested to see another way to test things.

  6. mbt1 commented on Mar 5, 2024

    @mbt1
    Collaborator
  7. vkuharsky commented on Mar 14, 2024

    @vkuharsky
    Author

    It's okay, I'll wait. Just post a link with the actual article after you publish it, or let me know somehow.

  8. vkuharsky commented on Sep 20, 2024

    @vkuharsky
    Author

    @mbt1 have you done something about that new functionality? If you still do not have enough time, can you just point to a set of stored procedures inside the tSQLt project?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions