如何找出方法調用是否源自測試類

嗨... 有什麼方法可以找出方法調用是否源自測試類？如果它來自一個測試類...那麼我需要爲類中的變量初始化一些虛擬值。我想用最小的源代碼更改編寫測試類... 該類遵循單例模式。因此，它的私有構造函數被調用，調用一些代碼阻止了我的測試。所以，我需要調用我的虛擬方法從內部私有構造函數，以便工作平穩..如何找出方法調用是否源自測試類

目前我做這個...

StackTraceElement[] stack = new Throwable().getStackTrace(); 
boolean blnFrmTesting = false; 
for (StackTraceElement stackTraceElement : stack) { 
    if(null != stackTraceElement && null != stackTraceElement.getFileName() && stackTraceElement.getFileName().endsWith("Test.java")) { 
     blnFrmTesting = true; 
     break; 
    } 
} 
return blnFrmTesting;

這是一個正確的方法...或者是（「@ Test」）

來源

2010-11-19 simplysiby

那麼，對於技術部分，我建議你應該試着看看類名是否包含Test，instaead的文件名，這是（儘管Java規範試圖規範化它）總是更加模糊（例如，考慮內部類）。

但是，以更通用的方式，您的代碼忽略了測試框架（JUniot，TestNG）及其相關生態系統的存在似乎忽略了大約十年的Java工程。特別是，爲了定義「虛擬價值」，嘲笑框架的領域是要走的路。目前有不少有趣的選擇：

顯然，他們可能會與你的單身（或沒有）干擾。然而，我必須告訴你，在IoC框架的角色中，單例模式現在通常被認爲是被棄用的。

來源

2010-11-19 10:14:54 Riduidel

嗨...感謝您的幫助...但我在測試中使用mockito ...事情是當我嘲笑這個類..靜態變量初始化declaration本身導致私人構造函數被調用並隨後嘗試調用一些不想要的方法，我想跳過... – simplysiby 2010-11-19 10:22:52

我認爲Riduidel的觀點是靜態初始化會使代碼非常難以測試。有一些黑客的解決方法，但是這會導致測試用例測試與生產代碼不同，生產代碼具有僅用於測試的功能，或測試代碼不提供完整和可讀的規範。 IoC框架和依賴注入可以保證在應用程序的生命週期中只有一個類的實例，而無需靜態全局訪問或可變靜態，從而產生更多可測試的代碼。 – NamshubWriter 2010-11-19 15:00:50

@NamshubWriter哦，那是Neal Stephenson的口頭用戶名！真喜歡它！ – Riduidel 2010-11-19 15:25:06

不管你是否找到了這個問題的答案，它可能更有意義的是不首先執行這個檢查，並相應地構造你的代碼......當測試調用時做別的事的代碼沒有經過真正的測試，是嗎？

你也可以看看使用DI模式和框架，如Guice或Spring ......這將使事情變得更容易測試，而可能導致更少和更簡單的代碼。

來源

2010-11-19 10:39:46

+1注射。如果一個班級需要「瞭解」自己以外的某些東西，請注入它。 – 2010-11-19 18:44:25

我普遍同意Sudhir，並不真正瞭解Riduidel建議如何使用Mocking。如果你想模擬班級的環境和社區，嘲笑是很好的。

我認爲你的方法很好。如果添加@Test註釋的檢查以及類擴展TestCase的事實，則可以真正改進它。如果你添加了對JUniot和testNG的支持，你甚至可以發佈你的代碼，而其他人可能會使用它。

但我認爲，你可能甚至可以簡化方法。我爲此使用了特殊的系統屬性。通常我必須確定代碼在應用程序服務器下運行，所以我使用了典型的應用程序服務器屬性。例如JBoss的jboss.server.name和Tomcat的catalina.base。如果JUnit沒有創建任何特殊屬性，則可以在測試開始和簽入代碼時自行完成。

來源

2010-11-19 11:03:29 AlexR

如何找出方法調用是否源自測試類

回答

相關問題