你在哪裏保存你的測試數據文件？

問題分類的分拆this。你把它們放在源代碼樹中嗎？你讓他們在源代碼控制？你在哪裏保存你的測試數據文件？

我在想，如果你的測試用例引用文件，那麼這些文件就是系統行爲規範的一部分，因此它們與系統的當前版本相關聯，因此它們應該被檢入源代碼控制。但我不認爲他們應該在本地檢查，因爲他們不需要，他們可能會相當大。所以我傾向於使用並行樹，如果項目的代碼文件位於$ svn/Code/foo/bar/baz，相關的測試數據文件位於$ svn/TestData/foo/bar/baz中，並且後者將直接從服務器使用某種常見的測試數據助手類（可能在本地緩存文件？）訪問，它們只能接受相對路徑並找出在哪裏找到它們。這有意義嗎？

我想這裏有一個相關的問題，我應該如何廣泛地使用外部文件進行測試。我認爲他們通常對更高級別的「接受」測試有好處。

來源

2009-08-03 Max Strini

但我不認爲他們應該在本地查出來，因爲他們並不需要是

爲什麼不呢？測試是任何複雜軟件系統的組成部分。如果他們不能沒有他們的數據運行，那麼他們變得毫無用處。

根據需要遠程獲取測試數據的想法很有趣，但當您需要做的只是運行測試時，您就會依賴於連接到Subversion服務器。我認爲這給應該做一件簡單的事情增加了不必要的複雜性;運行測試不應該成爲開發的瓶頸。

除此之外，您可能想要考慮一個事實，即您必須維護兩個不同的svn樹。當您有多個功能分支和版本或標籤時，這可能會變成一場噩夢。

要明確回答您的問題，我們將我們的測試文件保存在<項目根目錄>/tests中，以便每個分支都有自己的一組工作和有用的測試。

來源

2009-08-03 03:53:24

是的，我明白你在說什麼。我想在低級單元測試和高級驗收測試（可能包括性能測試方面並在某些情況下在多千兆字節的輸入數據上運行）之間需要進行清晰的分割？很明顯，我不應該在每次進行更改時都運行後者，因爲他們需要幾分鐘的時間才能運行，但我仍然希望以某種方式定期自動運行它們。正如你所看到的，我對於如何處理這樣的項目的測試仍然有些困惑，這些項目旨在處理大量和雜亂的數據輸入。 – 2009-08-03 04:11:55

我將它們添加到源代碼控制這樣

- Trunk 
    - Source 
    - Lib 
    - Tests 
     - DescriptiveTestName_1 
     - DescriptiveTestName_2 
- Branches 
    - v0.9 
     - Source 
     - Lib 
     - Tests

這樣，所有文件的源，庫和測試是爲每個版本，並很容易起牀的速度發展時，（和修復問題）。測試下的每個子目錄都包含測試所需的全部文件。

來源

2009-08-03 03:38:28

然後「測試」包含測試數據文件以及測試的源代碼嗎？或者是Source/test下的源代碼？ – MatrixFrog 2009-08-03 03:39:54

我們訂閱「源代碼控制下的所有東西」學派（肛門保留甚至沒有開始來形容我們）。這意味着我們負責的所有測試級別（單元，系統，集成，翻譯...），開發軟件CD/DVD映像，操作系統映像，VM的測試用例（代碼和數據）測試環境，所有的doco，基本上所有，如果團隊中的所有PC和軟件都將被盜用，將需要將開發/測試環境放在一起 - 除了硬件，但那只是因爲我們還沒有找到方法檢查它在:-)。

磁盤空間比重新獲得我們需要的所有東西所需的時間要便宜得多。當一個版本的軟件被公開發布時，我們實際上檢查了構建該版本所需的一切，將其刻錄到多張DVD並在原生硬件上測試該過程。然後，我們製作了多個副本，並將其分發到宇宙的四個角落......哎呀，對不起，我被帶走了。

但我們做盡我所說盡管構建DVD分佈到多個地理位置分開的位置（在這個星球上，而不是在整個宇宙）。

至於它在源代碼控制樹中的位置，我們樹的頂層始終是一個版本，與該版本相關的一切都存在於此。這給了大量的重複，但使事情變得非常容易管理。而且，通常情況下，磁盤存儲比人力資源便宜很多。

來源

2009-08-03 03:50:19 paxdiablo

我絕對認爲測試數據應該在與測試和源代碼相同的樹中進行版本化，以便輕鬆下載最新的代碼並運行測試。我設置了這樣的樹：

trunk/ 
    +- Source/ 
    +- TestSource/ 
    \- TestData/

測試然後引用../TestData/myTestData.xml或任何他們需要的。

來源

2009-08-03 03:55:11 pkaeding

你在哪裏保存你的測試數據文件？

回答

相關問題