是否有框架支持從註釋生成一些標準的單元測試？什麼我想到的一個例子是：自動創建單元測試（半）？
@HasPublicDefaultConstructor
public class Foo {
}
這顯然可以用來自動生成一個單元測試，檢查是否符有一個默認的構造函數。我是唯一一個想過這樣的事情的人嗎？ ;）雖然我對Java最感興趣，但其他語言的解決方案肯定也很有趣。
編輯：在回答美國洛特的回答，讓我澄清：
我想測試類是否有一個默認的構造函數。 （當然，這只是一個例子。）我可以通過編寫測試來完成，但是我覺得這很乏味。所以我正在尋找一個工具，可以在編譯時處理註釋（通過APT）併爲我生成測試。 有這樣的事嗎？如果不是，你認爲這是一個好主意嗎？
EiffelStudio CDD有一個有趣的方法。在調試模式下運行時，IDE會收集有關所調用方法的信息，並將上下文和調用放入單元測試中。使用按合同設計來檢測故障。我知道在Java之上有一些合約擴展的設計，所以這可能是一個不錯的方法。
對於您的具體示例，可能會更好地使用java APT（編譯時註釋處理）在編譯時更早地檢測此類問題。
Agitar有一個[商業] 產品,AgitarOne，生成JUnit測試。 我不確定它當前是否支持註釋，它是didn't in 2005。
Jtest是另一個面向Java的單元測試生成器，Parasoft還提供C++Test來生成C++單元測試。
我從未測試過任何一個;幾年前我已經閱讀過C++試卷，但並不確信。
問題是用附加註釋形式的「單元測試」信息「污染」生產代碼是否真的是一個好主意。 我個人會投反對票。
與您描述的測試默認構造函數的存在有點類似，我使用TestUtil來自動測試getter和setter。您可以使用XML文件或JavaDoc標記來調整測試選項。可悲的是，目前似乎沒有註釋的選項。
「處理註釋...併爲我的測試」
案件的數量有限，這可能是做的工作。但總的來說，它不能工作。
@StandardTestForClassHierarchy1
@StandardTestForClassHierarchy2
@StandardTestForClassHierarchy3
@StandardTestForSomeOtherFeature4
@AspectFeature5
@AspectFeature6
@HasPublicDefaultConstructor
@AspectX
@AspectY
class SomeClass extends SomeClassHierarchy implements SomeOtherFeature {
}
我無法從我的真實註解區分我單元測試的註解。
測試註釋是否描述了我的應用程序的運行時行爲？
如果他們做描述運行時的行爲，那麼他們的實時AOP的註解，而不是測試的描述，但真正的註解真正產生運行時代碼。並且註釋對模擬類有它自己的測試。
如果註釋不是描述運行時行爲，我現在有這種奇怪的非功能和功能註釋混亂。我在非功能註釋中看不到價值。
聽起來你正在尋找一種比標準Java更具說明性表達能力的編程語言。你假設的測試填補了空白，直到編譯器可以檢查聲明的語義。
我不知道任何工具可以將您建議的註釋類型轉換爲自動化測試。這聽起來像是一個很好的TDD練習，尤其是使用最近的（-ish）編譯器API。
您可以在編譯時使用APT檢測到這一點。
TL;博士：使用代碼檢查工具來代替。他們可以做你想做的事，不污染你的代碼，並且可以很容易地構建到自動構建過程中。
這聽起來不像是應該用單元測試來處理的東西。如果你堅持每個類都必須定義一個默認構造函數，那麼靜態代碼分析器可能是一個更好的選擇。 PMD絕對有這種事情的探測器。你也可以用Checkstyle強制這種檢測器。
這兩者都很容易定製，並且可以作爲您的單元測試的持續集成過程的一部分。
最關鍵的一點：這將允許你實現你想要的功能，而不用額外的註釋污染代碼庫。在我看到這個想法時，這是我的主要跳閘點：您已經創建了一個巨大的軟件管理問題。想象一下，使用默認的構造函數修改類是不可變的（因此要求在構建過程中完全設置對象）。你是否記得更新該班的所有註釋？你是否記得在其他調用這個方法的類中更改相關的註釋？等等。
我認爲你不可能爲自己節省任何東西。但是你會增加複雜性。
如果我想確保有一個默認的構造函數，我會添加以下到我的單元測試。
Foo foo = new Foo();
除了Snyke指出的 - 在編寫單元測試時，開發人員不應該更加關注嗎？通過使用生成的測試或半驢單元測試，您可以預期四分之一屁股功能。;-) 在最好的情況下，你可以期望單元測試框架，以便更快地實現更高的代碼覆蓋率。 – Shonzilla 2008-12-30 00:34:03