使用封閉源代碼應用程序發佈自動化測試的源代碼是常見甚至是好主意嗎？

Question

請給我指出任何欺騙或更好的地方發佈這個問題，你可能會發現。我以前從未銷售軟件，但是當我把自己放在客戶的鞋子裏時，我想，「我確實希望看到我購買的任何軟件的自動測試源代碼，它可以作爲真棒詳細的我正在購買的軟件的文檔！事實上，如果可能，我希望在購買之前將測試看作概念驗證。「

從賣家的角度來看，沒有理由隱藏測試代碼源（只要測試只通過「前門」訪問二進制文件並且不包含敏感數據），或者甚至將測試作爲開源源發佈從任何想要幫助我們的人那裏獲得幫助，並向潛在客戶證明軟件可以做些什麼。

那麼......是不是習慣，甚至是一個好主意，讓用戶看到（某些）自動測試代碼，甚至釋放它開源，對於你出售封閉源代碼的應用程序？

編輯：謝謝大家的有見地的意見。我應該澄清一下，我的目標是而不是來說「看看我的軟件質量如何！」而是「這是你如何使用軟件」（使用測試作爲文檔）。這是一個API;不涉及UI。我只是想演示如何使用它（公共接口），而不是內部工作。我真的很討厭那些很長的演示程序，但是通過API只展示「快樂的道路」，所以我一直在尋找一種改進的方法。

Answer 1

這個想法可能對客戶有好處，但對您不利。幾乎不可能創建一套自動化測試，不會利用您的實現的某些意外屬性，這些屬性沒有記錄，您希望稍後可以自由更改。一旦你讓這些測試出來，你基本上保證這些測試將在軟件的任何未來版本上運行。你不想把自己鎖在這樣的緊身衣上。

從理論上說，當然，你可以有一組將測試測試究竟什麼是公共接口暴露，不能多也不能少。但是隨着軟件的發展，這樣的測試套件的創建和維護將非常昂貴。 而這個想法令人想起其中一個次要apocrypha：

理論上，理論和實踐是相同的。在實踐中，他們不是。

Answer 2

它將暴露你的人複製你的實現，如果他們能夠準確地測試兼容性。

發佈API或設計爲暴露區域的測試可能是有意義的，但如果產品是封閉源代碼，則揭示內部工作的線索似乎是交叉目的。

Answer 3

它既不習慣也不是一個好主意，讓用戶看到任何自動化測試的測試結果。

想到這時候你去Ø醫生等。醫生可以通過將血液或其他物品送到實驗室進行任何測試。實驗室處理它並將結果發回給醫生。

如果您在之前發現之前的結果，您可能會完全誤解他們;而（s）他被訓練去理解什麼樣的價值觀是在正常的或者在正常範圍之外，更重要的是正常的東西對你來說是什麼。

同樣的道理也適用於這裏。您可能有一組測試始終失敗。最終用戶只會看到失敗，但不瞭解這些特定測試完全不會影響他們，因爲他們完全不會影響他們。例如，假設您的代碼庫中有一部分代碼不完整，並且已準備好供生產使用。但是，您可能已經設置了測試來強調該代碼。因爲知道您將在下個月完成該區域。

在這種情況下，您是否希望當前客戶說出一個觀點，即5％的測試失敗？或者，您願意讓您當前的客戶說「我使用的所有產品都完美無缺」。

- 我想補充一兩件事 -
最終用戶可以查看任何小故障作爲這意味着你的整個應用程序被打破的趨勢。大多數人唯一的參考是他們的車。如果電池沒電，那麼整個車都壞了。

這將導致你很多的挫折。特別是如果你對一些甚至可能無法在生產中重現的邊緣情況進行測試。所有的用戶都會看到有些東西壞了，因此不信任整個應用程序正常運行。

Answer 4

取而代之的是，做自己的自動測試並公開顯示結果。連續的一百個複選標記肯定會提高軟件的感知可靠性。

Answer 5

不習慣，我從來沒有見過這個開箱即用的軟件。

但是，我已經看到客戶（在更科學和/或工程領域）誰會用他們自己的測試和數據「認證」軟件以確保軟件不偏離他們自己的標準這可能與開發人員設置的不同）。

當認證完成（並被接受）後，新版本的軟件即可投入生產。