blocks|key|4321089|text|我个人的观点是:您将以一种逻辑且易于维护的方式创建测试类。现在，如果你有两个紧密相关的方法，我不明白你为什么要创建两个类。还有一件事要考虑你有多少测试方法。你不会想要有一个庞大的测试类。最终，您还必须维护测试类，因此要像对待常规代码库一样对待它们。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4321090|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

My personal opinion is this: you'll create test classes in such a way that's logical and easy to maintain. Now if you have two methods very closely related I don't see why you'll create two classes. One more thing to consider how many test methods you have. You don't want to have a huge test class. Eventually you'll also have to maintain the test classes, so treat them like your regular code base.

blocks|key|4321122|text|我不明白为每个方法引入测试类的原因。老实说，我从来没有见过这种测试策略。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4321123|当然，如果你有理由的话，你可以拆分你的测试类。您可以在单独的帮助器类中提取测试的公共部分。在某些情况下，测试类之间的继承也是合理的。|4321124|测试代码和生产代码没有区别。你的测试代码应该是清晰的，可读的和可维护的。我认为“每个方法一个测试类”的思想会毁了它。|offset|length|style|BOLD|4321125|entityMap^0|0|0|0|E|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@$F|O|G|P|H|I]]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

I can not see the reason of introducing test classes for each and every methods. Honestly, I've never seen this kind of test strategy.

Of course, you can break apart your test classes if you have reason for it. You can extract common parts of your tests in separated helper classes. In some cases inheritance between test classes is also reasonable. 

There is no difference between the test code and production code. Your test code should be clear, readable and maintainable. I think the "One Test-Class per method" ideology can ruin it.

blocks|key|863530|text|我认为这一切都是关于什么时候应用这样的东西。我想说的是，一般来说，您不应该为每个测试方法创建一个测试类。我建议将具有相同功能的方法(例如，单个类中的方法)分组到单个测试类中。但是，异常可能是一个极其复杂的方法，它需要数十个测试来验证其行为。在这种情况下，一个测试类可能是有用的。但是，您必须小心创建异常，因为这会使代码的结构方式不那么明显。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|863531|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I think it is all about when to apply such a thing. I'd say that in general you should not be creating a test class per test method. I would recommend grouping methods with the same functionality (e.g. the methods in a single class) in a single test class. However, an exception might be an extremely complex method that requires dozens of tests to verify its behavior. In such a case a single test class might be useful. You have to be careful creating exceptions though, as this makes the way the code is structured less obvious.

blocks|key|869854|text|为每个生产类创建一个测试类的主要优点是它简单易懂。如果你有Foo，你肯定知道Foo的所有单元测试都可以在FooTest中找到(或者不管你的命名习惯怎么叫它。您正在遵循单元测试类名的命名约定，不是吗？)|type|unstyled|depth|inlineStyleRanges|entityRanges|data|869855|出于可读性的目的，我建议您的团队定义一个有助于识别测试的命名约定。例如，我可以将其中一个测试命名为FooTest::DoSomething_ensureNullPointerThrowsException()。这样，读者不仅知道它是对Foo::DoSomething()的测试，而且还知道它是在测试空指针异常。|offset|length|style|CODE|869856|一般来说，如果某件事看起来“错误”或“难以做到”；如果你认为做一些不同的事情会更容易，因为你的项目似乎与其他人做的方式不一致；这通常是由于违反了一个或多个OO设计原则。深入寻找根本原因:为什么我在X问题上苦苦挣扎？为什么有人想让每个生产方法都有一个测试类？是不是每种方法都有一百个测试，开发人员认为更改一下就能让它们更好地组合在一起？真正的原因可能是他的方法有太多的责任，或者过于复杂。如果他的方法更简单，他可能会发现每种方法可能只需要5到10个测试。|869857|entityMap^0|0|1D|1J|39|I|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@$D|N|E|O|F|G]|$D|P|E|Q|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|R|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|K|$]]

The main advantage of creating one test class per production class is that it's simple and understandable. If you have Foo, you know for certain that all the unit tests for Foo can always be found in FooTest (or whatever your naming convention calls it. You are following a naming convention for the unit test class names, aren't you?)

For readability purposes, I recommend your team define a naming convention that helps identify the tests. For example, I might name one of the tests <code>FooTest::DoSomething_ensureNullPointerThrowsException()</code>. That way the reader knows not only it's a test for <code>Foo::DoSomething()</code>, but they also know it's testing for a null pointer exception.

In general, if something seems "wrong" or "hard to do"; if you think it would be easier to do something differently because your project just doesn't seem to mesh with the way everyone else does it; it's often due to violations of one or more of the OO design principles. Look deeply for the root cause: why am I struggling with issue X? Why does someone want want one test class per production method? Are there a hundred tests for each method and the developer thinks a change would keep them grouped together better? The real cause is likely that his methods have too much responsibility, or are overly complex. If his methods were simpler, he may find he needs perhaps only five or ten tests for each method.

since today I have used the pattern to create one test class per class. 
For example the class "Foo" with the methods "DoSomething" and "DoNothing" had one test class called "FooTests".

Now I have heard about creating one test class for every method. For the previous example this would mean I create two new classes called "DoSomethingTests" and "DoNothingTests" instead of the class "FooTests".

Is this a commonly used pattern and should I switch to this one, or is this furthermore an anti pattern?

Thanks for you help.

One Test-Class per method?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

从今天开始，我使用该模式为每个类创建一个测试类。例如，具有方法"DoSomething“和"DoNothing”的类"Foo“有一个名为"FooTests”的测试类。现在我听说要为每个方法创建一个测试类。对于前面的示例，这意味着我创建了两个新类"DoSomethingTests“和"DoNothingTests”，而不...

问每个方法只有一个测试类？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问每个方法只有一个测试类？EN