通过测试，使用@depends可以使测试方法依赖于另一个测试方法，这样，如果第一次测试失败，依赖于它的测试将被忽略，有没有办法用测试类做到这一点
例如，假设我有一个页面，我测试布局，检查图像是否显示，如果链接正确，这将是一个测试类，在此页面上是一个表单的链接，为此页面我将创建一个新的测试类检查其布局，验证等。
我想尝试和拉动的是，如果第一个Test Class的任何测试失败，那么第二个应该被跳过，因为第一个页面应该是正确的，因为它将是用户在进入第一个之前将看到的页面（除非他们输入第二页的网址，但必须假设用户是愚蠢的，因此不知道地址栏是如何工作的）
我还应该注意所有的测试都是使用TFS存储的，所以当团队进行相同的测试时，我们可能会有不同的phpunit.xml文件（一个人显然使用php.xml.dist并且不会改变它，因为它在Magento TAF中提到过一次，即使我使用.xml并且没有问题），因此，尝试在phpunit.xml中强制执行命令并不是那么有用（同时强制执行.xml中的顺序不会执行此依赖项操作）
答案 0 :(得分：3)
仅仅因为我们可以做一件事，并不意味着我们应该这样做。依靠其他测试成功执行的测试是一个坏主意。测试中的每一个体面的文本都会告诉你。听他们说。
答案 1 :(得分：1)
我不认为phpUnit有办法让一个测试类依赖于另一个。 （我开始写下一些令人浮想的黑客，但它们太丑陋而且很脆弱，我再次将它们删除了。）
我认为最佳方法是所有功能测试的一大类。然后你可以根据需要使用@depends。 ＆lt; - 这就是我对你实际问题的答案结束的地方： - ）
在你对Ross的回答的评论中，你说：“我被教导如果你在一个班级中有大量（测试）方法，那么你应该把它分成不同的类”看看为什么我们被允许打破这个规则，你必须低于表面，为什么这通常是一个好主意：一个类中的很多代码表明该类做得太多，使得更难更改，更难以测试。因此，您使用Extract Class重构将类拆分为更精细的功能。但绝不是机械的：每个类应该仍然是某事的漂亮，干净的抽象。
在单元测试中，最好将课程视为一种收集相关测试的方法。当一个测试依赖于另一个测试时，显然它们是相关的，所以它们应该在同一个类中。
如果一个2000行的文件让你感到不快，那么你可以做的一件事就是Extract Parent Class。进入您的父类会执行所有辅助函数和自定义断言。您将把所有实际测试保留在派生类中，但是仔细检查它们，看看哪些常用功能可以移动到共享函数，然后将该共享函数放在父类中。
回应罗斯关于@depends是邪恶的建议，我更愿意将其视为帮助你找到理想主义和现实世界约束之间的平衡。在理想世界中，您希望所有测试完全独立。这意味着每个测试都需要自己创建夹具并拆除。如果使用数据库，它应该创建自己的数据库（一个唯一的名称，以便将来可以并行运行），然后创建表，用数据填充它们等。（使用父类中的辅助函数）分享这个常见的夹具代码。）
另一方面，我们希望我们的测试在100毫秒内完成，这样它们就不会中断我们的创意流程。夹具共享有助于加速测试，但代价是消除了独立性。
对于网站的功能测试，我建议使用@depends来显示登录等明显的内容。如果你的大部分测试都会首先登录到网站，那么创建一个loginTest（）并使所有其他测试都依赖于它是很有意义的。如果登录不起作用，您肯定知道所有其他测试都将失败......并且正在浪费大量最有价值的程序员资源。
当它不那么明确时，我会偏离理想主义的一面，如果你需要，可以稍后再回过头来优化。