有幾種不同的PL / sql測試工具.

Steven Feuerstein已經寫了兩個

utplsql和

Quest Code Tester for Oracle(以前的QUTE).我是utplsql的粉絲,但它不再有一個積極的支持社區(這是一個恥辱).它也往往是相當冗長的,特別是在設置測試夾具時.它確實有純粹的PL / sql包的基數虛擬化;源代碼有點精彩,但它是FOSS.

QCTO帶有GUI,這意味著像其他Quest產品即TOAD一樣,它只是Windows.它并不能完全自動化測試數據生成,但它提供了一個支持它的接口.也像其他Quest產品一樣,QCTO雖然有免費軟件副本,但仍然獲得許可.

史蒂文(披露,他是我的Oracle英雄之一)已經編寫了所有PL / sql測試工具的功能比較.顯然,QOTC出來了,但我認為比較是誠實的. Check it out.

關于測試儀器在utplsql的建議

管理單元測試的測試數據可能是頸部真正的痛苦.不幸的是,utplsql不能承擔很大的負擔.所以

>始終測試已知值：

>避免使用dbms_random;

>嘗試將序列的使用限制在其值無關緊要的列中;

>日期也很棘手.避免硬編碼日期：使用用sysdate填充的變量.學習欣賞add_months(),last_day(),interval,trunc(sysdate,’MM’)等

>隔離其他用戶的測試數據.從頭開始構建它.盡可能使用獨特的值.

>只需要創建盡可能多的測試數據.體積測試是不同的責任.

>當測試程序更改數據時,為每個單元測試創??建特定的記錄.

>另外：不要依靠一個測試的成功輸出來提供來自另一個測試的輸入.

>當適當時,在單元測試之間簡單地報告數據共享記錄的測試程序.

>盡可能共享框架數據(例如引用的主鍵).

>使用自由文本字段(名稱,描述,注釋)來確定哪些測試或測試使用該記錄.

>最小化創建新記錄所涉及的工作：

>僅為測試套件和表的約束分配必需的值;

>盡可能使用默認值;

>盡可能地程序化.

其他事情要記住：

>設置測試夾具可能是一個耗時的練習.如果您有大量數據,請考慮構建一個過程來設置可以在每個會話中運行一次的靜態數據,并在ut_setup本身中僅包含volatile數據.這在測試只讀功能時特別有用.

>記住,創建測試數據是一個編程練習本身,并且容易出現錯誤.

>使用utplsql的所有功能.當推斷出易失性數據的值時,utAssert.EqQuery,utAssert.EqQueryValue,utAssert.EqTable,utAssert.EqTabCount和utAssert.Eq_RefC_Query都是非常有用的功能.

>當診斷測試運行時,我們不希望使用這些數據是有用的.所以考慮在ut_setup開始時有一個空心的ut_teardown過程并清除測試數據.

處理遺留代碼

評論加里的帖子讓我想起了另一件你可能會覺得有用的事情. Steven F寫了ulplsql作為JUnit的PL / sql實現,JUnit是Test First運動的Java先鋒.然而,TDD的技術也可以應用于大量的遺留代碼(在這種情況下,遺留代碼是沒有任何單元測試的任何程序集).

要牢記的關鍵是,您不必立即將所有內容都進行單元測試.逐步開始.構建新產品的單元測試,Test First.在應用更改之前,對要更改的位進行單元測試,以便您在進行更改后仍然可以工作.

在這方面有很多想法,但是(不可避免地,如果可恥),它主要來自OO程序員.邁克爾·羽毛是主要的章節.閱讀他的文章Working Effectively With Legacy Code.如果你覺得有用,他隨后寫了一本同名的書.

總結

以上是生活随笔為你收集整理的用oracle怎么测试,oracle – 如何(单位)测试数据密集的PL / SQL应用程序的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。