tms tck

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

Java平臺(tái)的TCK

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

這里只是有關(guān)TCK可用性的簡(jiǎn)短說明。 其中大多數(shù)截止到今天都還不可用，但要遵守許可條款和財(cái)務(wù)協(xié)議。 希望隨著Java Community Process即將發(fā)生的變化而改變。

一些JBoss女神可以治愈文檔

但是，一些聰明的人提出了解決方案。 幾個(gè)RedHats付出了巨大的努力，這并不奇怪。 最初是作為hibernate-validator項(xiàng)目的一部分而創(chuàng)建的一個(gè)小項(xiàng)目，它是BeanValidation的RI，在這里可以解決這些問題。 未知且本身未作記錄的jboss-test-audit項(xiàng)目本身稱為“ TCK測(cè)試覆蓋率報(bào)告的實(shí)用程序類”。 這完美地釘住了它。 它是對(duì)任何RI的非常輕量級(jí)但仍然強(qiáng)大的補(bǔ)充，它可以對(duì)特殊注釋的源進(jìn)行后處理，以收集任何旨在實(shí)施規(guī)范的項(xiàng)目的覆蓋率報(bào)告。 它已獲得Apache許可證2.0版的許可，您只需要很少的步驟就可以根據(jù)自己的設(shè)置運(yùn)行它。 這一切都始于規(guī)范。 這是一個(gè)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>

本文檔是您測(cè)試的基礎(chǔ)。 現(xiàn)在，您需要繼續(xù)進(jìn)行，并為所有測(cè)試配備相關(guān)的部分和斷言信息。 看起來可能如下所示：

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");}

結(jié)合一點(diǎn)Maven魔術(shù)（Maven處理器插件），所有注釋都將被解析，并且會(huì)生成一個(gè)有關(guān)總體覆蓋率的報(bào)告。 如果您想查看完整的引導(dǎo)程序示例，請(qǐng)?jiān)趃ithub.com/myfear上找到它。

堅(jiān)硬的零件

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

大量的想法

小實(shí)用程序類的工作相當(dāng)好。 但是仍有很大的改進(jìn)空間。 在此處具有一些支持性信息（例如問題編號(hào)或其他參考文獻(xiàn)）可能是一個(gè)有效的想法。 我也希望能夠在文檔中使用asciidoc。 但是我在這里不是抱怨，因?yàn)槲也粫?huì)自己更改它。 但是，如果有人感興趣，完整的內(nèi)容在github.com上 ，我相信這些人知道社區(qū)的工作方式并接受貢獻(xiàn)。

JCP的未來愿望

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

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

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

tms tck

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。