tms tck_记录合规性–关于TCK，规格和测试

tms tck

使用软件规格非常困难。不论在哪个地方提出；您最终遇到了一个大问题：是否已实现所有指定的内容并对其进行了测试？在瀑布驱动的方法学时代，这一直是一个问题，即使在撰写本文的今天，敏捷性和用户故事仍然不能保证您完美匹配。如今，许多敏捷方法都与测试驱动开发甚至行为驱动开发概念完美地结合在一起，可以将问题颠倒过来。而不是问“我的代码是否覆盖书面说明的每个句子？” 他们只是假设首先编写测试是获得所需覆盖率的有效方法。不利的一面是缺乏容易发生的文档。此外，您永远找不到合适的文档工作流程来将测试重构为一个文档。如果您查看诸如“技术兼容性工具包”（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处理器插件），所有注释都将被解析，并且会生成一个有关总体覆盖率的报告。如果您想查看完整的引导程序示例，请在github.com/myfear上找到它。

坚硬的零件

这显然是显而易见的。在测试中添加一些注释并不是您做过的最难的事情。真正困难的是将您的文档转换为该精美的审核xml格式。有很多方法可以做到这一点。鉴于事实，大多数领导JSR的公司都已采用某种硬核文档管理，这应该使它成为一生难忘的事情。如果您使用的是Microsoft Word，则还可以使用可用的xml模式与它一起编写格式正确的文档（这很痛苦！不要这样做！）。

大量的想法

小实用程序类的工作相当好。但是仍有很大的改进空间。在此处具有一些支持性信息（例如问题编号或其他参考文献）可能是一个有效的想法。我也希望能够在文档中使用asciidoc。但是我在这里不是抱怨，因为我不会自己更改它。但是，如果有人感兴趣，完整的内容在github.com上，我相信这些人知道社区的工作方式并接受贡献。