測試課程

Question

我昨天整理了一堂課，做了一些有用的工作。 我開始進行alpha測試，並且在某些時候意識到我正在為類本身添加與alpha測試相關的方法。 它打擊了我，他們不屬於那里。 在經過一些努力之后，我從基類中派生了一個測試類，該類也可以訪問受保護的成員。 我把所有與測試相關的方法，並在測試類中設置和拆除，並使基類傾斜，並且正如俗話所說的那樣。

在這里瀏覽了一段時間后，我發現一條評論建議使用這種技術，使測試類成為真正的類的朋友。

回想起來，這些技術對我來說應該是顯而易見的。

我正在尋找的是專門的alpha測試/單元測試類的技術，而不會增加被測試類的重量。

您個人使用了哪些技巧並推薦？

Answer 1

to your classes. 單元測試的目標之一是驗證類的 。 這意味着，一般來說，你不應該測試你班上骯臟的內臟。 單元測試應該與您的類的公共輸入和輸出交互，並驗證行為是否符合預期。 因此，您可以更改類的內部實現，而不會影響依賴於它的所有其他對象。 顯然，我不知道你情況中的細節，但我會說，作為一般規則，如果你的單元測試試圖找出課堂的私人細節，那你就做錯了。

編輯：另見： 這個問題 。 請注意，它可以完成（最佳答案），但也注意到第二位的答案（短邊）與我上面提到的或多或少相同。

Answer 2

聽起來你不想要單元測試，這正是一個類接口工作的驗證。 你不應該為了進行單元測試而改變你的課程。 如果您正在尋找一種方法來驗證對象的內部狀態以使其保持一致，那么您應該查看“ 按合同設計”方法，該方法可以驗證對象內部的狀態。

Answer 3

那些都很好。 我通常也希望測試類不僅是原始的，而且是完全不同的DLL / EXE，以及從編譯它的“真正的”DLL / EXE中測試“真正的”編譯類。 。

我發現的另一種技術是在測試工具中重新定義類。 完全復制類定義，但將所有內容都公開。 這允許測試工具對類進行“白盒”訪問，但實際的實現仍然來自真正的類代碼。

即

class myClass
{
private:
    int foo;
public:
    myClass() { foo = 0; }
}

接着：

class test_myClass
{
public:
    int foo;
public:
    test_myClass();
};

void test()
{
    myClass *c = new myClass();
    test_myClass *t = (test_myClass*)c;
    // All methods are called on c.
    // White-box access is available through t.
};

哦......而DevStudio 2008現在有一些非常酷的單元測試功能，包括聲明一個'朋友' 程序集的功能 ，它允許白盒訪問正在測試的程序集中的所有內部類。

Answer 4

我做了很多框架構建 - 基本上調用我想測試的類/接口。 班上沒有額外的工作。

我還建了幾次類，使公共方法變得虛擬。 我從那些派生出來並制作了測試類/對象。 測試對象方法稱為父（真實類）方法，並記錄所有調用和結果。 對於日志記錄而言，這比測試更多，但它也有效。

在關於單元測試之類的所有宣傳之前，我做了上述方法。 （大約1990年代后期）

那時它對我來說效果很好，但是我對Junit / nunit的東西並沒有做太多的事情，並且我真的很想讓它們在實際項目上發揮作用。

一種方法的樣本

上課

{...

public：virtual DoStuff（）; 。 ..};

ThingTest：public Thing

{

虛擬DoStuff（）

{

//記錄呼叫和參數。

//撥打父母

//記錄返回值

//返回返回值

}

};

Answer 5

eJames是正確的單元測試需要關注接口，即類的輸入產生正確的輸出。 任何私有或朋友變量都是實現的一部分，未經過特定測試。

如果您在類的私有例程中出錯，那么它將顯示錯誤的輸出。