blocks|key|975928|text|需要更多上下文才能回答您的问题。这要视情况而定。您的getXXX方法是从另一个正在测试的方法调用的吗？如果是这样，那么它已经测试过了。如果没有，客户端在做什么？这个方法还需要存在吗？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|975929|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|$]]

More context is required to answer your question. It just depends. Is your getXXX method called from another method that is under test? If so, then it's already tested. If not, what is the client doing? Does the method even need to exist?

blocks|key|226973|text|如果您所说的“硬编码属性”指的是这样的东西(在Java中)：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|226974|int+getTheAnswer()+{
++++return+42;
}|code-block|syntax|javascript|226975|然后你需要问自己--为什么不让它成为常量呢？例如,|226976|static+final+int+THE_ANSWER+=+42;|226977|在这种情况下，您不需要对其进行单元测试。|226978|在所有其他情况下，您应该考虑单元测试。|226979|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|R|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|S|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|T|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|U|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|V|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|P|$]]

If by “hardcoded properties” you mean something like this (in Java):

<pre><code>int getTheAnswer() {
 return 42;
}
</code></pre>

Then you need to ask yourself—why not make it a constant? For example,

<pre><code>static final int THE_ANSWER = 42;
</code></pre>

In such a case, you don’t need to unit-test it.

In all other cases, you should consider unit testing.

blocks|key|2824561|text|如果您使用TDD开发代码，那么您的单元测试将首先创建硬编码属性。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2824562|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|$]]

If you were developing your code using TDD, then your unit test is what would have created the hardcoded property in the first place.

blocks|key|226822|text|不，但更好的问题是，为什么要对值进行硬编码？我知道有时系统范围的配置设置很少(或从不)更改，但理想情况下，即使是这些设置也应该是可配置的，因此应该进行测试。永远不会改变的值仍然应该通过命名良好的常量来访问。如果您的系统仍处于早期开发阶段，那么您可能还没有构建这些组件，所以不要担心测试它们。;)|type|unstyled|depth|inlineStyleRanges|entityRanges|data|226823|嗯，好的，我猜例外可能是数学或物理常量。|226824|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

No, but a better question is why are you hardcoding values? I know sometimes you have system-wide config settings that rarely (or never) change, but ideally, even those should be configurable and so should be tested. Values that will NEVER change should still be accessed via well-named constants. If your system is still in early development, maybe you haven't built those components yet, so don't worry about testing them - yet. ;)

Hmm Ok I guess the exceptions might be math or physics constants.

blocks|key|1415341|text|除了其他答案中显而易见的几点：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1415342|您可能还想添加一个集成测试，以验证您的硬编码值是否能与其他组件很好地协同工作。|1415343|有时，您确实需要对值进行硬编码，例如，当实现要求进行能力测试的接口时，例如|1415344|interface+IDecoder+{+//+in+C#
++++bool+SupportStreaming+{+get;+}
}|code-block|syntax|javascript|1415345|当然，在实现上面的IDecoder接口时，必须硬编码SupportStreaming属性的值。|1415346|但重要的问题当然不是它是否会返回硬编码的值？但是Weather硬编码的值实际上是正确的值？，只有在进行集成测试和/或测试依赖于该值的其他单元/方法时才相关。|offset|length|style|BOLD|1415347|entityMap^0|0|0|0|0|0|O|L|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|V|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|W|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|X|8|@]|9|@]|A|$I|J]]|$1|K|3|L|5|6|7|Y|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|Z|8|@$O|10|P|11|Q|R]]|9|@]|A|$]]|$1|S|3|-4|5|6|7|12|8|@]|9|@]|A|$]]]|T|$]]

Apart from obvious points from other answers:

You might want to add also, an integration test to verify that your hardcoded values actually works and plays well with other components.

Sometimes you do needs to hard code values, i.e. when implementing interfaces that asks for a capability tests, something like

<pre><code>interface IDecoder { // in C#
 bool SupportStreaming { get; }
}
</code></pre>

Of course, when implementing the IDecoder interface above, you'd have to hard code a value for the SupportStreaming property.

But the important question would of course not be Weather the it returns the hardcoded value? but Weather the hardcoded value actually is the correct value? which is only relevant when doing integration testing and/or testing other units/methods that depends on the value.

blocks|key|972176|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|972177|我们应该测试我们已经知道答案的值吗？|blockquote|972178|972179|972180|你怎么知道的?可能有人更改了代码，作为回归，它现在返回一些其他的东西。|972181|如果这些值是公共API的一部分，那么您应该测试它们。|972182|并且您应该根据文字值测试它们，而不是您正在测试的程序定义的常量(因为这些常量可能已经被错误地更改)。|972183|+//+good
+assertEquals(+"Number",+myClass.getType(1234));
+assertEquals(+"Number",+MyClass.TYPE_NUMBER);

+//+not+so+good
+assertEquals(+MyClass.TYPE_NUMBER,+myClass.getType(1234));+|code-block|syntax|javascript|972184|entityMap^0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|-4|4|5|6|S|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|T|7|@]|8|@]|9|$]]|$1|D|3|-4|4|5|6|U|7|@]|8|@]|9|$]]|$1|E|3|-4|4|5|6|V|7|@]|8|@]|9|$]]|$1|F|3|G|4|5|6|W|7|@]|8|@]|9|$]]|$1|H|3|I|4|5|6|X|7|@]|8|@]|9|$]]|$1|J|3|K|4|5|6|Y|7|@]|8|@]|9|$]]|$1|L|3|M|4|N|6|Z|7|@]|8|@]|9|$O|P]]|$1|Q|3|-4|4|5|6|10|7|@]|8|@]|9|$]]]|R|$]]

<blockquote>
 Should we be testing values that we already know the answer to?
</blockquote>

How do you know that? Someone might have changed the code, and as a regression, it returns something else now.

If those values are part of the public API you should test them.

And you should test them against the literal value, not a constant defined by the program you are testing (because those could have been changed in error).

<pre><code> // good
 assertEquals( "Number", myClass.getType(1234));
 assertEquals( "Number", MyClass.TYPE_NUMBER);

 // not so good
 assertEquals( MyClass.TYPE_NUMBER, myClass.getType(1234)); 
</code></pre>

blocks|key|2824545|text|就我个人而言，我不会费心测试任何声明式的东西。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2824546|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 personally don't bother with testing anything that's declarative.

Should we be testing values that we already know the answer to?

If a value is important enough to be a dedicated hard code value then should should it be important enough of to change a test at the same time as the value? or is this just overkill?!

Should you unit test the return value of Hardcode Properties?

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

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

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

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

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

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

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

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

我们是否应该测试我们已经知道答案的值？如果一个值足够重要，以至于是一个专用的硬编码值，那么它是否应该足够重要，以便在更改测试的同时更改该值？还是说这太夸张了？！

问是否应该对Hardcode Properties的返回值进行单元测试？
EN

回答 7

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问是否应该对Hardcode Properties的返回值进行单元测试？EN

回答 7

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问是否应该对Hardcode Properties的返回值进行单元测试？
EN