我已經開始研究一個小型的ruby項目，該項目將有許多不同的數據結構和算法的示例實現。現在只需要刷新一段時間我還沒有完成的東西，但是我希望能夠像Ruby Koans那樣創建一些類似的數據結構的單元測試，但實現爲空（在另一個分支中有完整的實現）。它可以被用作一個很好的學習工具或代碼kata。如何對數據結構的內部（組織）進行單元測試？
不過，我有想出寫測試的好辦法麻煩。我不能僅僅測試公衆行爲，因爲這不會告訴我有關實施的情況，這在這裏很重要。例如，普通BST和紅黑樹的公共接口將是相同的，但RB樹具有非常具體的數據組織要求。我將如何測試？
不知道你正在做什麼，但如果你想爲隨後可以實施和/或以各種方式進一步專業化各種數據結構提供了常用接口，我不看你怎麼可以寫任何測試尚不存在的具體實施。
您可以編寫測試的通用接口，以確保所有的實現符合該接口指定的合同。例如。排序樹的所有實現都應該正確排列它們的元素等等。作爲附註，這實際上不是單元測試，而是功能/驗收測試。
對於紅黑樹，儘管可以編寫一套附加（可選）測試，以便在插入&刪除後驗證樹是否被正確地重新排序。這可以，並應通過公共界面進行測試。例如。將一系列元素添加到樹中，以便在不重新排序的情況下使樹不平衡，然後檢查樹結構以確保它正確地重新排序。
測試實際執行一類通常是一個壞主意。你對班級中每種方法的合同進行測試要好得多。
想想看：如果公共接口是一樣的，不會對單元測試是相同的，而不管實施的？
的單元測試數據結構（在Java中）一個很好的例子是Google Collections framework。它有大約35,000個。請注意，他們都沒有測試內部實現：相反，他們驗證每個方法和類的合同。
單元測試是關於測試一個課程的實際實施情況，根據包括我自己在內的很多人來說，這是一個非常好的主意。 （但是，這裏所討論的測試並不是每個定義的單元測試。） – 2010-04-05 14:31:43
一般來說，我將單元測試視爲測試類的預期行爲，但不應假設任何有關實際實現的內容（因此類可以重構或者只要外觀可見的行爲仍然正確，就選擇不同的算法）。這裏的問題是，如果你正在談論一個特定的算法，那麼內部行爲就是合約的一部分，這正是我在這裏所做的。 – Herms 2010-04-05 14:53:18
如何公開暴露內部結構是我不知道的。至少不是沒有公開訪問實際的樹節點，我寧願不這樣做（儘管這對我的目的可能是正確的） – Herms 2010-04-05 14:51:34
@條我假設任何集合的接口不是沒有方法來訪問個人元素。對於樹來說，這將包括查詢和遍歷節點的子節點，獲得特定節點的路徑等。 – 2010-04-05 15:08:35
我主要想到的是「接口」是一個標準的Map類集合。雖然也許這不是看待它的正確方法。 – Herms 2010-04-05 15:17:15