使用軟件規格非常困難。 不論在哪個地方提出； 您最終遇到了一個大問題：是否已實施并測試了所有指定的內容？ 在瀑布驅動的方法學時代，這一直是一個問題，即使在撰寫本文的今天，敏捷性和用戶故事仍然不能保證您完美匹配。 如今，許多敏捷方法都與測試驅動開發甚至行為驅動開發概念完美地結合在一起，可以將問題顛倒過來。 而不是問“我的代碼是否覆蓋書面說明的每個句子？” 那些人只是假設首先編寫測試是獲得所需覆蓋率的有效方法。 不利之處是缺乏容易發生的文檔。 此外，您永遠找不到合適的文檔工作流程來將測試重構為一個文檔。 如果您查看諸如“技術兼容性套件”（TCK）之類的東西，這些東西本質上或多或少是從任何基于文檔的書面規范中收集的，那么對單個解決方案和項目可能有效的方法就結束了。

Java平臺的TCK

深入探討此類主題始終是使開發社區兩極分化的一個不錯的選擇。 特別是因為文檔仍然是一個話題，往往會被遺忘或完全拖延。 對我而言，文檔是可能水平上的關鍵。 在框架級別，它確保您的用戶不會掙扎，并且為快速采用奠定了良好的基礎。 對我來說，Arquillian項目和團隊在成立的第一年就做得非常出色。 即使在項目級別，也可以快速進出新團隊成員而又不會失去知識。 但是還有另一個領域，不僅可以從中受益，而且與文檔有很強的聯系：Java TCK。 所有Java平臺都將Java規范請求（JSR）定義為語言改進的重點。 技術兼容性套件（TCK）是一套測試套件，至少名義上檢查Java規范請求（JSR）的特定所謂實現是否符合要求。 鑒于事實，大多數規范都存在于某些Office之類的文檔中，并以PDF的形式發布以供審閱和評論，幾乎不可能說TCK完全具有原始規范的定義范圍。 這充其量是可怕的。 在大多數情況下，這很煩人，因為參考實現（RI）只是忘記覆蓋規范的某些部分，而用戶必須以特定的方式處理由此產生的錯誤或行為。 如果有可能的話。

這里只是有關TCK可用性的簡短說明。 其中大多數截止到今天都還不可用，但要遵守許可條款和財務協議。 希望隨著Java Community Process即將進行的更改，這種情況將會改變。

一些JBoss女神可以治愈文檔

但是，一些聰明的人提出了解決方案。 幾個RedHats付出了巨大的努力，這并不奇怪。 最初是作為hibernate-validator項目的一部分而創建的一個小項目，它是BeanValidation的RI，在這里可以解決這些問題。 未知且幾乎未做文檔記錄的jboss-test-audit項目自稱為“ TCK測試覆蓋率報告的實用程序類”。 這完美地釘住了它。 它是對任何RI的非常輕量級但仍然強大的補充，它可以對特殊注釋的源進行后處理，以收集任何旨在實施規范的項目的覆蓋率報告。 它已獲得Apache許可，版本2.0的許可，您只需要很少的步驟就可以根據自己的設置運行該程序。 這一切都始于規范。 這是一個xml文檔，它定義了不同的部分和必需的斷言。

<specification><section id="1" title="Chapter 1 - Introduction"/><section id ="2" title="Chapter 2 - What's new"><assertion id="a"><text>A simple sample test</text></assertion></section></specification>

本文檔是您測試的基礎。 現在，您需要繼續進行，并為所有測試配備相關的部分和斷言信息。 看起來可能如下所示：

SpecVersion(spec = "spectests", version = "1.0.0") public class AppTest {@Test@SpecAssertion(section = "2", id = "a")public void simpleTestForAssertion() {App app = new App();assertEquals(app.sayHello("Markus"), "Hello Markus");}

結合一點Maven魔術（maven-processor-plugin），所有注釋都將被解析，并且會生成一個有關總體覆蓋率的報告。 如果您想看完整的引導示例，請在github.com/myfear上找到它。

堅硬的零件

這顯然是顯而易見的。 在測試中添加一些注釋并不是您做過的最難的事情。 真正困難的是將您的文檔轉換成該精美的審核xml格式。 有很多方法可以做到這一點。 鑒于事實，領導JSR的大多數公司都已實施某種硬核文檔管理，這應該使它成為一生難忘的事情。 如果您使用的是Microsoft Word，則還可以使用可用的xml模式與它一起編寫格式正確的文檔（這很痛苦！不要這樣做！）。

大量的想法

小實用程序類的工作相當好。 但是，仍有很大的改進空間。 在此處具有一些支持性信息（例如問題編號或其他參考文獻）可能是一個有效的想法。 我也希望能夠在文檔中使用asciidoc。 但是我在這里不是抱怨，因為我不會自己更改它。 但是，如果有人感興趣，完整的內容在github.com上 ，我相信這些人知道社區的工作方式并接受貢獻。

JCP的未來愿望

有了這種簡單的方法，與JSR一起促進采用是一件好事。 因此，如果您喜歡它，可以與您信任的EC成員聯系，并使他/她意識到這一點，并將其作為想法列入他們的清單。

參考： 法規遵從性文檔–關于我們的JCG合作伙伴 Markus Eisele在有關Java的企業軟件開發中的 TCK，規范和測試的信息。

翻譯自: https://www.javacodegeeks.com/2013/06/documenting-compliance-about-tcks-specifications-and-testing.html

總結

以上是生活随笔為你收集整理的记录合规性–关于TCK，规格和测试的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。