MENU
  1. ホーム
  2. SQL
  3. Metodi di test e debug per le stored procedure SQL

Metodi di test e debug per le stored procedure SQL

SQL

Nello sviluppo delle stored procedure SQL, comprendere i metodi accurati di test e debug è di fondamentale importanza. Le stored procedure sono potenti strumenti per sfruttare al massimo le funzionalità del database, ma sono soggette a bug e problemi di prestazioni, quindi test e debug appropriati sono indispensabili. In questo articolo, spiegheremo in dettaglio i metodi per test e debug efficienti, fornendo tecniche pratiche utili nello sviluppo reale.

Indice

Metodi di test di base per le stored procedure

Illustreremo i metodi di base e i passaggi per testare le stored procedure. Di seguito sono riportati i metodi di test comunemente utilizzati in SQL Server.

Creazione del piano di test

Creare un piano di test e decidere quali scenari testare. È importante includere casi normali, casi anomali e valori limite.

Esecuzione dei casi di test

Eseguire la stored procedure basandosi sui casi di test preparati in anticipo. In questo modo, è possibile confrontare i risultati attesi con quelli effettivi.

Verifica dei risultati

Dopo l’esecuzione del test, controllare i risultati ottenuti e verificare se corrispondono a quelli attesi. Controllare anche la coerenza dei dati e le prestazioni.

Iterazione dei test

Se vengono trovati bug, apportare le correzioni e ripetere i test. Attraverso questo processo iterativo, si migliora la qualità della stored procedure.

Seguendo questi passaggi di base, è possibile verificare che la stored procedure funzioni come previsto.

Metodo di verifica dei parametri di input

La verifica dei parametri di input delle stored procedure è essenziale per garantire un’elaborazione accurata dei dati. Di seguito sono descritte le modalità di controllo dei parametri di input e la gestione degli errori.

Controllo del tipo di dati dei parametri

Verificare che i parametri di input siano del tipo di dati corretto. In SQL Server, è possibile utilizzare la funzione ISNUMERIC o TRY_CONVERT per controllare i tipi numerici o di data.

Controllo dei valori NULL

Utilizzare l’istruzione IF per verificare che i parametri non siano NULL. Impostare un valore predefinito se necessario.

IF @parameter IS NULL
BEGIN
    SET @parameter = 'default_value';
END

Controllo dell’intervallo dei parametri

Verificare che i parametri di input siano all’interno dell’intervallo consentito. Ad esempio, controllare se un numero rientra in un intervallo specifico o se la lunghezza di una stringa è entro un certo limite.

IF @parameter < 0 OR @parameter > 100
BEGIN
    RAISERROR('Parametro fuori dall'intervallo', 16, 1);
END

Controllo della coerenza dei dati

Verificare la coerenza dei dati di input in base a chiavi esterne o altre regole di business. Ad esempio, controllare se l’ID utente esiste.

IF NOT EXISTS (SELECT 1 FROM Users WHERE UserID = @UserID)
BEGIN
    RAISERROR('UserID non valido', 16, 1);
END

Gestione degli errori

Se durante la verifica dei parametri di input si verifica un errore, restituire un messaggio di errore appropriato e interrompere l’elaborazione. Utilizzare il blocco TRY...CATCH per gestire gli errori.

BEGIN TRY
    -- Codice di verifica dei parametri
END TRY
BEGIN CATCH
    -- Codice di gestione degli errori
    DECLARE @ErrorMessage NVARCHAR(4000) = ERROR_MESSAGE();
    RAISERROR(@ErrorMessage, 16, 1);
END CATCH

Utilizzando questi metodi, è possibile eseguire una verifica efficace dei parametri di input, migliorando l’affidabilità e la robustezza delle stored procedure.

Preparazione dei dati di test

La creazione e la gestione dei dati di test sono fondamentali nel processo di test delle stored procedure. Qui presentiamo le migliori pratiche per la preparazione dei dati di test.

Definizione dei requisiti dei dati di test

Inizialmente, definire i dati necessari per lo scenario di test. Ciò include dati di casi normali, casi anomali e dati di valori limite.

Modalità di preparazione dei dati

I dati di test possono essere inseriti manualmente, utilizzati tramite script automatici o copiati da un database esistente. Di seguito è riportato un esempio di inserimento dei dati di test utilizzando uno script.

INSERT INTO TestTable (Column1, Column2, Column3)
VALUES 
('Value1', 'Value2', 100),
('Value3', 'Value4', 200),
('Value5', 'Value6', 300);

Ripristino e pulizia dei dati

Dopo il termine dei test, è importante ripristinare il database allo stato originale. A tale scopo, utilizzare script per eliminare o reimpostare i dati utilizzati nel test.

DELETE FROM TestTable WHERE Column1 IN ('Value1', 'Value3', 'Value5');

Varietà e copertura dei dati

Utilizzare diversi set di dati per verificare che la stored procedure funzioni correttamente in tutti gli scenari. È importante includere valori estremi e formati di dati imprevisti.

Gestione dei dati di test

È importante avere una strategia per gestire i dati di test. Ciò include la gestione delle versioni dei dati di test e la creazione di dataset di test riutilizzabili in più casi di test.

-- Script di inserimento dei dati di test
CREATE PROCEDURE InsertTestData
AS
BEGIN
    INSERT INTO TestTable (Column1, Column2, Column3)
    VALUES 
    ('Value1', 'Value2', 100),
    ('Value3', 'Value4', 200),
    ('Value5', 'Value6', 300);
END

-- Script di pulizia dei dati di test
CREATE PROCEDURE CleanupTestData
AS
BEGIN
    DELETE FROM TestTable WHERE Column1 IN ('Value1', 'Value3', 'Value5');
END

Eseguendo questi passaggi, la preparazione e la gestione dei dati di test diventano più semplici, facilitando il processo di test delle stored procedure.

Strumenti di debug di SQL Server Management Studio (SSMS)

SQL Server Management Studio (SSMS) offre potenti strumenti per supportare il debug delle stored procedure. Qui spieghiamo come utilizzare gli strumenti di debug di SSMS e i loro vantaggi.

Avvio del debug

Per avviare il debug di una stored procedure in SSMS, fare clic con il tasto destro sulla stored procedure che si desidera eseguire il debug e selezionare “Debug”. In questo modo, la stored procedure verrà eseguita in modalità di debug.

Impostazione dei punti di interruzione

Impostare i punti di interruzione per sospendere l’esecuzione della stored procedure in una riga specifica. Questo aiuta a esaminare in dettaglio alcune parti del codice.

-- Fare clic sul bordo sinistro della riga in cui si desidera impostare il punto di interruzione
SELECT * FROM TestTable;

Monitoraggio delle variabili

In modalità di debug, è possibile monitorare il valore corrente delle variabili in tempo reale. Ciò consente di tracciare le variazioni dei valori delle variabili e identificare la causa dei problemi.

Utilizzo della finestra di monitoraggio

Utilizzare le finestre “Locali” o “Monitoraggio” di SSMS per visualizzare i valori di variabili o espressioni.

Esecuzione passo-passo

Eseguire la stored procedure riga per riga durante il debug per esaminare il comportamento di ogni passaggio. Questo è particolarmente utile per il debug di logiche complesse o cicli.

Step In, Step Over, Step Out

  • Step In: Entra in una funzione o in un’altra stored procedure all’interno della stored procedure.
  • Step Over: Passa alla riga successiva.
  • Step Out: Esegue fino alla fine della stored procedure corrente e ritorna al chiamante.

Verifica dello stack delle chiamate

Durante il debug, verificare lo stack delle chiamate per comprendere il percorso di esecuzione corrente e la struttura gerarchica delle stored procedure chiamate. Questo consente di capire visivamente come viene eseguito il codice.

Vantaggi

Utilizzare gli strumenti di debug di SSMS offre i seguenti vantaggi.

  • Individuazione in tempo reale dei problemi: È possibile identificare e correggere rapidamente i problemi durante l’esecuzione.
  • Analisi dettagliata: È possibile esaminare in dettaglio i valori delle variabili e il percorso di esecuzione.
  • Risoluzione efficiente dei problemi: È possibile individuare rapidamente la causa dei problemi e risolverli.

Sfruttando questi strumenti di debug, è possibile ottimizzare il processo di debug delle stored procedure e creare codice di alta qualità.

Debug con l’uso di PRINT e registrazione dei log

L’uso di PRINT e dei log è un metodo efficace per identificare i problemi nelle stored procedure. Questo permette di verificare il flusso di esecuzione del codice e i valori delle variabili. Di seguito, spieghiamo con esempi concreti.

Debug con PRINT

Utilizzare l’istruzione PRINT per visualizzare messaggi o valori delle variabili durante l’esecuzione, consentendo di controllare lo stato della stored procedure.

DECLARE @counter INT = 1;
WHILE @counter <= 10
BEGIN
    PRINT 'Valore del contatore: ' + CAST(@counter AS NVARCHAR(10));
    SET @counter = @counter + 1;
END

In questo esempio, il valore della variabile @counter viene stampato a ogni iterazione, consentendo di controllare l’avanzamento del ciclo.

Debug con l’uso di una tabella di log

Per conservare informazioni di debug più dettagliate, è possibile creare una tabella di log dedicata per registrare le informazioni.

CREATE TABLE DebugLog (
    LogID INT IDENTITY(1,1) PRIMARY KEY,
    LogMessage NVARCHAR(4000),
    LogDate DATETIME DEFAULT GETDATE()
);

INSERT INTO DebugLog (LogMessage)
VALUES ('Stored procedure avviata');

Registrare messaggi di log nei punti chiave della stored procedure consente di analizzare successivamente le informazioni di debug.

Gestione degli errori con TRY…CATCH e log degli errori

Per registrare informazioni dettagliate in caso di errore, utilizzare un blocco TRY...CATCH per salvare il messaggio di errore nella tabella di log.

BEGIN TRY
    -- Esempio: Elaborazione della stored procedure
    DECLARE @result INT;
    SET @result = 10 / 0;  -- Generazione intenzionale di un errore
END TRY
BEGIN CATCH
    DECLARE @ErrorMessage NVARCHAR(4000) = ERROR_MESSAGE();
    INSERT INTO DebugLog (LogMessage)
    VALUES (@ErrorMessage);
    THROW;  -- Rilancia l'errore
END CATCH

In questo esempio, se si verifica un errore, il messaggio di errore viene salvato nel log, aiutando a identificare la causa del problema.

Pulizia delle informazioni di debug

Dopo il termine del debug, eliminare le informazioni di log inutili per mantenere il database in uno stato pulito.

DELETE FROM DebugLog WHERE LogDate < DATEADD(DAY, -7, GETDATE());

Questa query elimina i dati di log più vecchi di una settimana.

Utilizzando PRINT e i log, è possibile facilitare il debug delle stored procedure e identificare e risolvere rapidamente i problemi. Questo migliora l’efficienza dello sviluppo e consente di mantenere codice di alta qualità.

Tecniche di gestione delle eccezioni e degli errori

La gestione delle eccezioni e degli errori è essenziale per migliorare l’affidabilità delle stored procedure. Qui vengono presentati i concetti di base della gestione delle eccezioni e le modalità efficaci di gestione degli errori.

Uso del blocco TRY…CATCH

In SQL Server, è possibile utilizzare il blocco TRY...CATCH per controllare cosa fare quando si verifica un errore.

BEGIN TRY
    -- Esempio: Elaborazione dell'inserimento di dati
    INSERT INTO Employees (EmployeeID, Name)
    VALUES (1, 'John Doe');
END TRY
BEGIN CATCH
    -- Gestione dell'errore
    DECLARE @ErrorMessage NVARCHAR(4000) = ERROR_MESSAGE();
    RAISERROR(@ErrorMessage, 16, 1);
END CATCH

In questo esempio, se si verifica un errore nel blocco TRY, il controllo passa al blocco CATCH, dove viene visualizzato un messaggio di errore.

Registrazione dei messaggi di errore

Registrare informazioni dettagliate sugli errori consente di analizzare i problemi in un secondo momento.

BEGIN TRY
    -- Esempio: Elaborazione dell'aggiornamento di dati
    UPDATE Employees SET Name = 'Jane Doe' WHERE EmployeeID = 1;
END TRY
BEGIN CATCH
    DECLARE @ErrorMessage NVARCHAR(4000) = ERROR_MESSAGE();
    DECLARE @ErrorSeverity INT = ERROR_SEVERITY();
    DECLARE @ErrorState INT = ERROR_STATE();

    INSERT INTO ErrorLog (ErrorMessage, ErrorSeverity, ErrorState, ErrorDate)
    VALUES (@ErrorMessage, @ErrorSeverity, @ErrorState, GETDATE());

    -- Opzionale: Rilanciare l'errore
    THROW;
END CATCH

In questo esempio, il messaggio di errore e i dettagli vengono registrati nella tabella ErrorLog.

Transazioni e gestione degli errori

Utilizzare le transazioni per trattare più istruzioni come un’unità e mantenere la coerenza dei dati eseguendo un rollback in caso di errore.

BEGIN TRY
    BEGIN TRANSACTION;

    -- Esempio: Inserimento e aggiornamento dei dati
    INSERT INTO Orders (OrderID, ProductID, Quantity)
    VALUES (1, 100, 10);

    UPDATE Inventory SET Quantity = Quantity - 10 WHERE ProductID = 100;

    -- Commit
    COMMIT TRANSACTION;
END TRY
BEGIN CATCH
    -- Rollback
    IF @@TRANCOUNT > 0
        ROLLBACK TRANSACTION;

    DECLARE @ErrorMessage NVARCHAR(4000) = ERROR_MESSAGE();
    RAISERROR(@ErrorMessage, 16, 1);
END CATCH

In questo esempio, la transazione viene avviata e, in caso di errore, viene eseguito un rollback per mantenere la coerenza dei dati.

Uso di messaggi di errore personalizzati

È possibile registrare messaggi di errore personalizzati nella tabella sys.messages di SQL Server e utilizzarli con RAISERROR.

-- Registrazione del messaggio di errore personalizzato
EXEC sp_addmessage @msgnum = 50001, @severity = 16, @msgtext = N'Messaggio di errore personalizzato.';

-- Uso del messaggio di errore personalizzato
RAISERROR(50001, 16, 1);

Utilizzare messaggi di errore personalizzati consente di comunicare in modo più chiaro e specifico il contenuto dell’errore.

Con l’uso di queste tecniche, è possibile implementare una gestione efficace delle eccezioni e degli errori, migliorando l’affidabilità e la manutenibilità delle stored procedure.

Automazione dei test unitari

L’automazione dei test unitari è essenziale per garantire la qualità delle stored procedure. Questo consente di verificare che le modifiche al codice non influenzino negativamente altre parti. Di seguito, spieghiamo l’automazione dei test unitari e i suoi vantaggi.

Introduzione al framework tSQLt

tSQLt, un framework di test unitari per SQL Server, consente di eseguire test direttamente nel database. Per iniziare, installare tSQLt.

EXEC sp_configure 'clr enabled', 1;
RECONFIGURE;
-- Eseguire lo script di installazione di tSQLt

Creazione di una classe di test

Creare una classe di test dedicata per la stored procedure da testare.

EXEC tSQLt.NewTestClass 'TestEmployeeProcedures';

Creazione di casi di test

Definire i casi di test all’interno della classe di test e verificare i risultati attesi.

CREATE PROCEDURE TestEmployeeProcedures.[test that AddEmployee inserts new employee]
AS
BEGIN
    -- Arrange: Preparazione dei dati di test
    EXEC tSQLt.FakeTable 'Employees';

    -- Act: Esecuzione della stored procedure
    EXEC AddEmployee @EmployeeID = 1, @Name = 'John Doe';

    -- Assert: Verifica del risultato
    EXEC tSQLt.AssertEqualsTable 'Employees', (SELECT * FROM Employees WHERE EmployeeID = 1 AND Name = 'John Doe');
END;

In questo esempio, viene verificato se la stored procedure AddEmployee inserisce correttamente un nuovo dipendente.

Esecuzione dei test

Eseguire tutti i casi di test in blocco e verificare i risultati.

EXEC tSQLt.RunAll;

I risultati del test vengono mostrati in un report che include i test riusciti e quelli falliti.

Integrazione con l’integrazione continua

Integrare i test unitari con strumenti di integrazione continua (CI) consente di eseguire automaticamente i test ogni volta che il codice viene inviato al repository. In questo modo, è possibile rilevare e correggere i problemi tempestivamente.

Esempio: Integrazione con Azure DevOps

Configurare la pipeline di Azure DevOps per eseguire automaticamente i test tSQLt.

trigger:
- main

pool:
  vmImage: 'ubuntu-latest'

steps:
- task: UseDotNet@2
  inputs:
    packageType: 'sdk'
    version: '5.x'
    installationPath: $(Agent.ToolsDirectory)/dotnet

- script: |
    sqlcmd -S $(DB_SERVER) -d $(DB_NAME) -U $(DB_USER) -P $(DB_PASS) -i Install-tSQLt.sql
    sqlcmd -S $(DB_SERVER) -d $(DB_NAME) -U $(DB_USER) -P $(DB_PASS) -Q "EXEC tSQLt.RunAll"
  displayName: 'Esegui i test tSQLt'

Con questa configurazione, i test tSQLt vengono eseguiti automaticamente ogni volta che vengono apportate modifiche al branch main del repository Git.

Vantaggi

  • Esecuzione efficiente dei test: È più veloce e accurato rispetto ai test manuali.
  • Rilevamento precoce dei bug: Verifica che le modifiche al codice non influiscano su altre funzionalità.
  • Miglioramento della qualità: I test continui migliorano la qualità del codice.

Implementando queste tecniche, è possibile automatizzare i test unitari delle stored procedure, migliorando l’efficienza e l’affidabilità dell’intero processo di sviluppo.

Conclusione

Comprendere i metodi di test e debug delle stored procedure SQL è una competenza cruciale nello sviluppo di database. Di seguito riepiloghiamo i punti principali trattati in questo articolo.

I metodi di test di base per le stored procedure includono la creazione di un piano di test, l’esecuzione dei casi di test, la verifica dei risultati e l’iterazione dei test. Per quanto riguarda la verifica dei parametri di input, è necessario eseguire controlli sul tipo di dati, sui valori NULL, sull’intervallo e sulla coerenza dei dati, implementando la gestione degli errori tramite il blocco TRY…CATCH.

Per la preparazione dei dati di test, sono importanti la definizione dei requisiti dei dati di test, la preparazione dei dati, il ripristino e la pulizia, la varietà e la copertura dei dati, e le strategie di gestione dei dati. Gli strumenti di debug di SQL Server Management Studio (SSMS) consentono di impostare punti di interruzione, monitorare le variabili, eseguire passi singoli e controllare lo stack delle chiamate, ottimizzando il processo di debug.

I metodi di debug con PRINT e log utilizzano PRINT e tabelle di log per registrare informazioni dettagliate in caso di errore, consentendo di identificare e risolvere rapidamente i problemi. Le tecniche di gestione delle eccezioni e degli errori includono l’uso di TRY…CATCH, la registrazione dei messaggi di errore, l’uso delle transazioni e l’uso di messaggi di errore personalizzati.

Infine, l’automazione dei test unitari prevede l’introduzione del framework tSQLt, la creazione di classi e casi di test, e l’integrazione con strumenti CI per garantire un’esecuzione efficiente dei test e migliorare la qualità del codice.

Utilizzando questi metodi di test e debug, è possibile migliorare la qualità delle stored procedure SQL e aumentare l’efficienza dell’intero processo di sviluppo.

SQL
Debugging Gestione degli errori Metodi di Test Procedure memorizzate SQL SQL Server Strumenti di Debug Test Unitari Validazione dei Parametri
Indice