做网站流量怎么赚钱,莆田建设企业网站,自己做的网站让别人看到,wordpress企业手机主题使用软件规格非常困难。 不论在哪个地方提出#xff1b; 您最终遇到了一个大问题#xff1a;是否已实施并测试了所有指定的内容#xff1f; 在瀑布驱动的方法学时代#xff0c;这一直是一个问题#xff0c;即使在撰写本文的今天#xff0c;敏捷性和用户故事仍然不能保证您… 使用软件规格非常困难。 不论在哪个地方提出 您最终遇到了一个大问题是否已实施并测试了所有指定的内容 在瀑布驱动的方法学时代这一直是一个问题即使在撰写本文的今天敏捷性和用户故事仍然不能保证您完美匹配。 如今许多敏捷方法都与测试驱动开发甚至行为驱动开发概念完美地结合在一起可以将问题颠倒过来。 而不是问“我的代码是否覆盖书面说明的每个句子” 那些人只是假设首先编写测试是获得所需覆盖率的有效方法。 不利之处是缺乏容易发生的文档。 此外您永远找不到合适的文档工作流程来将测试重构为一个文档。 如果您查看诸如“技术兼容性套件”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文档它定义了不同的部分和必需的断言。 specificationsection id1 titleChapter 1 - Introduction/section id 2 titleChapter 2 - Whats newassertion idatextA simple sample test/text/assertion/section/specification 本文档是您测试的基础。 现在您需要继续进行并为所有测试配备相关的部分和断言信息。 看起来可能如下所示 SpecVersion(spec spectests, version 1.0.0)
public class AppTest {TestSpecAssertion(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
