gestión de errores de tsqlt que supera el controlador de errores de procedimiento almacenado (unidad)

Question

Al intentar validar un GUID proporcionado por el usuario dentro de un procedimiento almacenado, se utilizó un enfoque simple; tomar la entrada del usuario como un CHAR (36) y luego CAST explícitamente como UNIQUEIDENTIFIER dentro de TRY CATCH. El CATCH luego burbujea el error con una descripción de error personalizada usando un RAISERROR.

Ejecutando el procedimiento almacenado manualmente, todo funciona como se espera y se produce un error.

Crea una prueba tSQLt para llamar a la unidad (el procedimiento con validación de GUID) y manejar el error que se produce y comparar con el error esperado continuamente falla con un error de transacción; tSQLt ha detectado un error y se maneja dentro del marco tSQLt.

Esto me sugiere que tSQLt está manejando la severidad de un error al CASTAR a un tipo de datos diferente y está impidiendo que TRY/CATCH dentro del procedimiento almacenado lo maneje. Al igual que los procedimientos anidados, a veces ignoran el TRY/CATCH dentro del procedimiento secundario y se repiten hasta el procedimiento principal; ejemplo que es si el niño proc. hace referencia a una tabla que no existe.

¿Alguien ha tenido un problema similar? Simplemente para validar mi línea de pensamiento actual.

He eliminado la prueba y está siendo probado en otro lugar, pero esto me ha causado un "agujero" en mi unidad DB.

Finalmente, creo que debería mencionar que sé que puedo realizar una validación diferente en un parámetro CHAR suministrado, que no sea CAST, y generar un error de esa manera, pero esta es una consulta tSQLt y no una consulta tSQL.

EDITAR

Ejemplo del código:

@sGUID es un CHAR (36) y es un parámetro pasado al procedimiento.

BEGIN TRY 
    SELECT CAST(@sGUID AS UNIQUEIDENTIFIER) 
END TRY 
BEGIN CATCH 
    RAISERROR('Invalid GUID format',16,1) 
END CATCH 

La línea SELECT no desencadena la captura tSQLt parece intervenir antes de mano y lanza el error de transacción ROLLBACK.

Answer 1

Cuando llama a RAISEERROR(), finaliza la transacción que está ejecutando tSQLt -> de ahí el error de transacción que está viendo.

Para mejorar esto para el propósito de la unidad de pruebas, una opción que podría considerar sería la de sustituir la declaración RAISEERROR() con una llamada a un procedimiento almacenado personalizado que sólo se contiene RAISERROR(). De esta forma, puede realizar una prueba unitaria de ese procedimiento almacenado por separado.

BEGIN TRY 
    SELECT CAST(@sGUID AS UNIQUEIDENTIFIER) 
END TRY 
BEGIN CATCH 
    EXEC dbo.customprocedure 
    --RAISERROR('Invalid GUID format',16,1) 
END CATCH