如何测试架构？在架构还在形成时，是否可以完成与测试相关的事情？
我计划迭代，但在开始考虑测试之前，我不想等待整个架构完成（即使它非常粗糙）。
更新： 我正在使用 Code Complete 中使用的架构一词。
换句话说，在这一秒，我的架构是一堆纸，显示各种blob如何相互作用（例如，一张纸显示一个遗留系统与一个解剖/切片和切片的立面对话，反过来与主要网站应用程序交谈。）
稍后，我会将它充实到公共课程/方法的角度。在那之后，我会写出私有方法签名和戳算法，虽然我已经在研究它们的高级别事情，比如分类文本。
答案 0 :(得分：3)
通常，“测试架构”意味着测试applicative and technical architecture（而不是业务和功能测试，而不是“测试”和“验证”）。 这不是“单元测试”或“持续集成”或TDD，而是从开始到结束测试所有系统（由许多模块组成）的黑盒方法。
您确实可以开始设计的不是一个，而是几个测试策略：当它们涉及“架构”时，它们通常是“系统范围”的测试，意味着专用的基础架构（网络，服务器接近部署目标）。 / p>
因此，在设计第一个“架构”测试时，您可以考虑：
所有这些主题都可以在架构完善时解决，以便在开始时更有效地支持开发工作。
答案 1 :(得分：1)
你的结构是一个设计文件吗？
您将需要检查。
检查可以捕获错误以及测试。检查将很快发现“错误”。
将文件放在一群知识渊博的人面前。让他们阅读并告诉你哪里有问题。重做您的文档并将其返回给他们。继续这个过程，直到知识渊博的听众完全清楚你在做什么，并且所有人都相信它会起作用。
希望您的文档的编写方式使您的读者能够理解相互作用并查看相关工作，即使它们是抽象的。
答案 2 :(得分：1)
设计规则＃1：不要认为任何事情都很简单，认为系统很容易通常意味着尚未考虑到必须编码的要求或范围。
设计规则＃2：不要设计一些东西，然后将其交给开发人员，告诉他们当你没有实际编码或使用该技术时很容易。
设计规则＃3：新技术不是让你所有问题都消失的银弹。所有新技术都存在集成挑战，并且通常还有许多缺陷尚未被供应商修复。
牢记这些规则，请按以下步骤操作：
定义引入或考虑的技术假设，未知数和新技术。
验证任何未经证实的假设 - 即您或团队之前未曾使用过的内容。阅读白皮书或供应商新闻稿不算数。如果之前没有做过或者以新的方式使用它，请确保它在构建系统之前有效。
构建一个硬编码的丢弃原型来验证系统交互，并且可以通过最少的解决方法解决未知问题。删除计划中不起作用的任何部分，并在它成为消耗您的体系结构的黑洞之前找到另一种方法。
答案 3 :(得分：0)
如果你想迭代，你应该只为迭代设计那么多。 Architecture通常被视为高于design的一层。这意味着我使用分层MVC架构来决定如何设计我的类结构。
如果您要为第一次迭代构建整体程序结构而不添加可以测试的功能和事物，那么您做错了。通过迭代过程继续前进的好处之一是，您不需要在不需要它的方向上进行过多的设计。
选择您要构建的程序并使用三个最重要的功能。考虑如何实现它们以及如何为其设计类结构。考虑可能会改变的事物，并使它们在您的设计中更改。然后开始你的第一次迭代。 在开始第一次迭代之前考虑架构选择，您使用的是基于客户端服务器的体系结构MVC吗？您是否拥有数据库层或类似的东西。这些选择会影响您以后的设计选择。
如需进一步阅读，我建议您从肯特贝克那里http://en.wikipedia.org/wiki/Iterative_and_incremental_development和规划XP-Programming。
答案 4 :(得分：0)
基于软件架构的测试技术
本论文提出了一种实用，有效且可自动化的技术，用于在架构级别测试架构关系。它还提供了一个概念验证工具来生成测试要求。
答案 5 :(得分：0)
ATAM是你应该看的东西。这是评估体系结构的一种方法。关键步骤是提出“场景”，基本上是系统未来可能需要做的事情，更改或扩展需求。例如，让系统在不同的操作系统上运行。然后，您可以评估架构如何适应这些场景。
答案 6 :(得分：0)
自从健身功能开始流行以来，针对建筑进行单元测试的想法就变得非常流行。有一些非常有用的框架，例如ArchUnit，可用于编写健身函数。