如果您像我一樣，則可能已經花費了很多時間在查詢分析器中開發代碼。在您對代碼感到滿意之後，可以立即對開發服務器上的測試數據庫運行一個或兩個專設 測試。如果看起來沒有什麼問題，您便可以將代碼投入生產。如果這是一段關鍵代碼，或者該代碼較為復雜，則您可能會執行更多的檢查，以避免後驗剖析。甚至在這種情況下，您也可能屏息以待。
這就是我在大部分職業生涯中所采用的編碼方式。哦，有時我會存儲測試查詢以供將來使用，這通常是因為總裁/CEO/CIO/部門經理習慣於大約每周就改變一下他或她的要求。但是，除此以外，我不會再做什麼。我通常在查詢分析器或它的 Oracle/Access/FoxPro 等效工具外部用專設 查詢進行測試。更高強度的測試需要使用查詢分析器調試器。在絕望的情形下，需要使用 PRINT 語句。
目前存在 一種更好的方式。
超越專設 測試
當我的 SIL 部門采用極限編程 (XP) 時，我們還采用了該方法論的單元測試部分，而它們兩者都使我成為更出色的開發人員。但是，即使您不在 XP 環境中工作，您仍然可以從 XP 風格的單元測試中獲益。
單元測試不同於接受測試。單元測試用於測試較小的代碼塊（例如，存儲過程），而接受測試更多地涉及到用戶是否可以接受 UI。以下是我發現的單元測試的五個優點：
•它們能夠找出應該承擔責任的當事人。您是否收到過電子郵件，告訴您應該修復程序錯誤，而這實際上是其他某個人所作更改的副作用？好，如果您具有一些零散的測試查詢，請將它們包裝到可以定期運行（或許是在晚上）的存儲過程中。請確保在單元測試失敗時能夠生成電子郵件。
•；生成庫不需要花費很長時間。每個存儲過程和每個存儲函數都應當具有為它編寫的測試，而觸發器也應該如此。如果這聽起來有些苛刻，那麼請想一想，能夠在問題到達生產服務器之前捕捉到它，從而拯救您自己，將會是一種多麼好的感覺。如果您具有大量舊式代碼，那麼為每個單元編寫測試可能需要多年的工作，並且您也不能僅僅為了編寫測試而停止新的開發工作。但是，您可以為每段新代碼編寫測試，也可以為您修改的每個過程編寫測試。用不了多長時間，您就會為關鍵的舊式代碼和新代碼編寫眾多的測試。
•輕松創建准確的代碼文檔。每個過程或函數都應當用不同的參數組合調用。這不僅能夠確保代碼按預期方式工作，而且還提供了有關您的工作的最新而准確的文檔。另外一個編碼員只需查看您的測試，就可以了解對您的過程進行調用的示例。誰知道呢？某一天，這另一個編碼員可能就是您自己。
•它們迫使您預先進行一點兒思考和計劃。您應當在編寫實際的過程或函數之前編寫自己的單元測試。“什麼？”您說，“我抗議！我們如何為尚未進行編碼的東西編寫測試？”
•有一個很老的笑話，它講的是：有一個經理說：“我將弄清楚他們需要什麼。其余的人開始編碼。”那麼，編碼員在知道他們需要編寫什麼之前是無法開始工作的，不是嗎？當您首先編寫測試時，您將被迫考慮在開始編寫該過程之前，您希望該過程完成什麼工作。
