blocks|key|334756|text|请参阅Michael+Feathers'+definition|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|334757|334758|如果满足以下条件，则测试不是单元测试：|blockquote|334759|334760|334761|334762|它与数据库|unordered-list-item|334763|通过网络通信|334764|它触及文件系统|334765|它不能与任何其他单元测试同时运行|334766|您必须对您的环境执行特殊操作(如编辑配置文件)才能运行它。|334767|334768|entityMap|0|LINK|mutability|MUTABLE|url|http://www.artima.com/weblogs/viewpost.jsp?thread=126923^0|3|S|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|14|8|@]|9|@$A|15|B|16|1|17]]|C|$]]|$1|D|3|-4|5|6|7|18|8|@]|9|@]|C|$]]|$1|E|3|F|5|G|7|19|8|@]|9|@]|C|$]]|$1|H|3|-4|5|6|7|1A|8|@]|9|@]|C|$]]|$1|I|3|-4|5|6|7|1B|8|@]|9|@]|C|$]]|$1|J|3|-4|5|6|7|1C|8|@]|9|@]|C|$]]|$1|K|3|L|5|M|7|1D|8|@]|9|@]|C|$]]|$1|N|3|O|5|M|7|1E|8|@]|9|@]|C|$]]|$1|P|3|Q|5|M|7|1F|8|@]|9|@]|C|$]]|$1|R|3|S|5|M|7|1G|8|@]|9|@]|C|$]]|$1|T|3|U|5|M|7|1H|8|@]|9|@]|C|$]]|$1|V|3|-4|5|6|7|1I|8|@]|9|@]|C|$]]|$1|W|3|-4|5|6|7|1J|8|@]|9|@]|C|$]]]|X|$Y|$5|Z|10|11|C|$12|13]]]]

See <a href="http://www.artima.com/weblogs/viewpost.jsp?thread=126923" rel="noreferrer">Michael Feathers' definition</a>

<blockquote>
 A test is not a unit test if:
 
 <ul>
 <li>It talks to the database</li>
 <li>It communicates across the network</li>
 <li>It touches the file system</li>
 <li>It can't run at the same time as any of your other unit tests</li>
 <li>You have to do special things to your environment (such as editing
 config files) to run it.</li>
 </ul>
</blockquote>

blocks|key|3097293|text|如果测试不是单元测试，那么测试就不是单元测试。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3097294|说真的，这就是问题所在。|3097295|单元测试中“单元”的概念并没有明确的定义，事实上，到目前为止，我找到的最好的定义实际上不是一个定义，因为它是循环的:单元测试中的单元是可以独立测试的最小的东西。|3097296|这为您提供了两个检查点:是否隔离测试？它是不是最小的东西呢？|3097297|请注意，这两个都是上下文相关的。在一种情况下可能是最小的事情(例如，整个对象)在另一种情况下可能只是单个方法的一小部分。在一种情况下的隔离可能是在另一种情况下(例如，在内存管理的语言中，您永远不会在与垃圾收集器隔离的情况下运行，大多数情况下这是无关紧要的，但有时可能不是)。|3097298|entityMap^0|0|0|0|0|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|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

A test is not a unit test if it is not testing a unit.

Seriously, that's all there is to it.

The concept of "unit" in unit testing is not well-defined, in fact, the best definition I have found so far, isn't actually a definition because it is circular: a unit in a unit test is the smallest possible thing that can be tested in isolation.

This gives you two checkpoints: is it tested in isolation? And is it the smallest possible thing?

Please note that both of these are context-dependent. What might be the smallest possible thing in one situation (say, an entire object) might in another situation just one small piece of one single method. And what counts as isolation in one situation might be in another (e.g. in a memory-managed language, you never run in isolation from the garbage collector, and most of the time that is irrelevant, but sometimes it might not be).

blocks|key|3097012|text|它没有断言，并且不期望抛出异常。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3097013|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|$]]

It has no asserts, and is not expecting an exception to be thrown.

blocks|key|3097376|text|很难的..。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3097377|对我来说，单元测试验证isolation中的一个特定逻辑。这意味着，我提取了一些逻辑，将其从其余部分中提取出来(如果有必要，可以通过模拟依赖项)，并通过探索不同类型的控制流来测试该逻辑-一个单元(整个)。|offset|length|style|BOLD|3097378|但在另一个side...can上，我们总是100%25说正确或不正确？？不是要变得有哲理，但--正如Michael+says在他的帖子中所说的那样：|3097379|执行++的|3097380|+测试还不错。通常，它们值得编写，并且可以在单元测试工具中编写。然而，能够将它们与真正的单元测试分开是很重要的，这样我们就可以保留一组测试，无论何时进行更改，都可以快速运行。|blockquote|3097381|3097382|3097383|那么，为什么我不应该编写一个单元测试来验证解析逻辑，例如，通过访问我的测试文件夹中的文件系统中的某个虚拟文件(就像DeploymentItem允许的MS测试一样)？|3097384|当然-如前所述-我们应该将这些类型的测试与其他类型的测试分开(也许在JUnit中的一个单独的测试套件中)。但我认为，如果一个人在使用there...clearly时感到舒服，那么他也应该编写这些测试，然后始终记住，单元测试应该只是单独测试一个片段。|3097385|在我看来，最重要的是这些测试运行得很快，并且不会花费太长的时间。它们可以重复且非常频繁地运行。|3097386|entityMap|0|LINK|mutability|MUTABLE|url|http://www.artima.com/weblogs/viewpost.jsp?thread=126923^0|0|B|9|0|1C|C|0|0|4|1|0|1|2E|0|0|0|0|2A|0|0|3G|0|0|1B|0^^$0|@$1|2|3|4|5|6|7|14|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|15|8|@$D|16|E|17|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|18|8|@]|9|@$D|19|E|1A|1|1B]]|A|$]]|$1|J|3|K|5|6|7|1C|8|@$D|1D|E|1E|F|G]]|9|@]|A|$]]|$1|L|3|M|5|N|7|1F|8|@$D|1G|E|1H|F|G]]|9|@]|A|$]]|$1|O|3|-4|5|6|7|1I|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|1J|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1K|8|@$D|1L|E|1M|F|G]]|9|@]|A|$]]|$1|S|3|T|5|6|7|1N|8|@$D|1O|E|1P|F|G]]|9|@]|A|$]]|$1|U|3|V|5|6|7|1Q|8|@$D|1R|E|1S|F|G]]|9|@]|A|$]]|$1|W|3|-4|5|6|7|1T|8|@]|9|@]|A|$]]]|X|$Y|$5|Z|10|11|A|$12|13]]]]

Difficult one...

For me a unit test verifies one specific piece of logic in isolation. Meaning, I take some logic, extract it from the rest (if necessary by mocking dependencies) and test just that logic - a unit (of the whole) - by exploring different kind of possible control flows.

But on the other side...can we always 100% say correct or incorrect?? Not to become philosophical, but - as also <a href="http://www.artima.com/weblogs/viewpost.jsp?thread=126923" rel="nofollow noreferrer">Michael says</a> in his post:

<blockquote>
 Tests that do <a href="https://stackoverflow.com/questions/1257560/when-is-a-test-not-a-unit-test/1257583#1257583">these things</a> aren't bad.
 Often they are worth writing, and they
 can be written in a unit test harness.
 However, it is important to be able to
 separate them from true unit tests so
 that we can keep a set of tests that
 we can run fast whenever we make our
 changes.
</blockquote>

So why shouldn't I write a unit test that verifies the logic of parsing for instance an xls file by accessing some dummy file from the file system in my test folder (like MS tests allow with the DeploymentItem)?

Of course - as mentioned - we should separate these kind of tests from the others (maybe in a separate test suite in JUnit). But I think one should also write those tests if he feels comfortable in having them there...clearly then always again remembering that a unit test should just test a piece in isolation.

What is most important in my eyes is that these tests run fast and don't take too long s.t. they can be run repeatedly and very often.

blocks|key|332302|text|在以下情况下，测试不是单元测试：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|332303|332304|it一次测试不止一件事(即它测试两件事如何协同工作)-然后它就是集成测试|unordered-list-item|332305|332306|良好单元测试的检查表：|332307|它们是自动化的implement|332308|they+|332309|
|332310|它们很容易编写并保留供将来使用，一旦写入|332311|332312|，它们可以由任何人运行|332313|332314|它们可以通过按一下按钮来运行<|332315|332316|>H117>它们运行速度很快<代码>H218<代码>F219|332317|332318|332319|
<>H117|332320|一些更多的最佳实践(没有特别的重要性顺序)：|332321|控制测试应该与集成测试(较慢)分开，以便它们可以像控制不包含太多逻辑一样频繁地运行(最好没有控制structures)|332322|every测试应该只测试一件事(因此，它们应该只包含一个断言)|332323|332324|断言中使用的期望值应该是硬编码的，而不是在测试依赖项(文件系统、时间、内存等)时计算出来的。|332325|332326|应替换为存根测试应重新创建测试关闭时的初始状态|332327|332328|在断言中，最好使用"contains...“策略，而不是“严格相等...”策略(即，我们需要集合中的某些值、字符串中的某些字符等)|332329|332330|这是我从Roy+Osherove的书中提取的知识的一部分-+|332331|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1N|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|1O|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|1P|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|G|3|H|5|6|7|1R|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|1S|8|@]|9|@]|A|$]]|$1|K|3|L|5|E|7|1T|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|1U|8|@]|9|@]|A|$]]|$1|O|3|P|5|E|7|1V|8|@]|9|@]|A|$]]|$1|Q|3|N|5|6|7|1W|8|@]|9|@]|A|$]]|$1|R|3|S|5|E|7|1X|8|@]|9|@]|A|$]]|$1|T|3|N|5|6|7|1Y|8|@]|9|@]|A|$]]|$1|U|3|V|5|E|7|1Z|8|@]|9|@]|A|$]]|$1|W|3|N|5|6|7|20|8|@]|9|@]|A|$]]|$1|X|3|Y|5|E|7|21|8|@]|9|@]|A|$]]|$1|Z|3|N|5|6|7|22|8|@]|9|@]|A|$]]|$1|10|3|-4|5|E|7|23|8|@]|9|@]|A|$]]|$1|11|3|12|5|6|7|24|8|@]|9|@]|A|$]]|$1|13|3|14|5|6|7|25|8|@]|9|@]|A|$]]|$1|15|3|16|5|6|7|26|8|@]|9|@]|A|$]]|$1|17|3|18|5|E|7|27|8|@]|9|@]|A|$]]|$1|19|3|N|5|6|7|28|8|@]|9|@]|A|$]]|$1|1A|3|1B|5|E|7|29|8|@]|9|@]|A|$]]|$1|1C|3|N|5|6|7|2A|8|@]|9|@]|A|$]]|$1|1D|3|1E|5|E|7|2B|8|@]|9|@]|A|$]]|$1|1F|3|N|5|6|7|2C|8|@]|9|@]|A|$]]|$1|1G|3|1H|5|E|7|2D|8|@]|9|@]|A|$]]|$1|1I|3|-4|5|6|7|2E|8|@]|9|@]|A|$]]|$1|1J|3|1K|5|6|7|2F|8|@]|9|@]|A|$]]|$1|1L|3|-4|5|6|7|2G|8|@]|9|@]|A|$]]]|1M|$]]

A test is not an Unit Test when:

<ul>
<li>it tests more than one thing at once (i.e. it tests how two things work together) - then it is an integration test</li>
</ul>

Checklist for good unit tests:

<ul>
<li>they are automated</li>
<li>they are repeatable</li>
<li>they are easy to implement</li>
<li>they remain for future use, once written</li>
<li>they can be run by anyone</li>
<li>they can be run by the push of a button</li>
<li>they run quickly </li>
</ul>

Some more best practices (in no particular order of importance):

<ul>
<li>tests should be separated from integration tests (which are slower), so that they can be run fast as frequently as possible</li>
<li>they should not comprise too much logic (preferably, no control structures)</li>
<li>every test should test only one thing (thus, they should contain only one assert)</li>
<li>the expected values used in assertions should be hard-coded and not computed at test run-time</li>
<li>external dependencies (filesystem, time, memory etc.) should be replaced by stubs</li>
<li>test should recreate the initial state at test shutdown</li>
<li>in assertions, it is better to use a "contains..." policy, rather than "is strictly equal..." policy (i.e. we expect certain values in a collection, certain characters in a string etc.)</li>
</ul>

This is part of the knowledge I have extracted from Roy Osherove's book - <a href="http://artofunittesting.com/">The Art of Unit Testing</a>

blocks|key|3097100|text|跨多个可能失败的单元实现测试将不是单元测试。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3097101|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|$]]

Implementing a test across multiple possibly failing units would not be a unit test.

blocks|key|332164|text|复杂的问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|332165|假设我要编写一些业务逻辑，所有业务逻辑都需要通过某种形式的DAL访问数据。|332166|假设出于测试目的，我模拟DAL单元(通过创建“mockingbird”)。|332167|但这些模仿鸟当然是它们自身的附加单位。因此，即使在使用模拟时，当我想要对业务逻辑模块进行单元测试时，似乎仍然会违反“不涉及其他单元”的想法。|332168|当然，众所周知，“为DAL创建模拟鸟”可以使您的测试本身无效，因为您的mockingbird在某些特定方面偏离了DAL。|332169|结论:对以任何方式依赖于任何DAL的业务模块进行“真正的单元测试”是完全不可能的，问号？|332170|Corrolary+:唯一可能的事情(“真正的”!)单元测试是DAL本身吗，问号？|332171|推论:假设"DAL“通常是一些DBMS的ORM或DML，并且这些产品通常是作为”经过验证的技术“购买的，那么做任何单元测试有什么附加值呢？|332172|entityMap^0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|T|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|V|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|W|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|X|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|Y|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|Q|$]]

Intricate question.

Say I am to program some business logic and all business logic needs to get to the data via some form of DAL.

Say that for the purposes of testing, I mock the DAL units (by creating "mockingbirds").

But those mockingbirds are of course, additional units in their own right. So even when using mocks, it might seem like I'm still bound to violate the idea of "no other units involved" when I want to unit-test my business logic module.

Of course, it is generally known that "creating mockingbirds for the DAL" can invalidate your very test itself on the count that your mockingbird deviates in some particular aspect from the DAL.

Conclusion : it is outright impossible to do "genuine unit-tests" on business modules that depend in any way on any kind of DAL, question mark ?

Corrolary : the only thing that can possible be ("genuinely" !) unit-tested is the DAL itself, question mark ?

Corrolary of the corrolary : given that the "DAL" is usually either an ORM or the very DML of some DBMS, and given that those products are usually bought as being "proven technology", what is the added value of doing any unit tests what so ever, question mark ?

blocks|key|3097392|text|在确定测试是否是单元测试之后，下一个问题是，它是一个good+unit+test吗|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3097393|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/61400/what-makes-a-good-unit-test^0|Q|E|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

After whether a test is a unit test or not is settled the next question is, is it a <a href="https://stackoverflow.com/questions/61400/what-makes-a-good-unit-test">good unit test</a>?

I am looking for rules like:

A test is not a unit-test if:

<ul>
<li>it communicates with a database</li>
<li>it cannot run in parallel with other tests</li>
<li>uses the "environment" like registry or file system</li>
</ul>

What else is there?

When is a Test not a Unit-test?

单元测试

集成测试

文件系统

内存管理

数据库

我正在寻找这样的规则：如果满足以下条件，则测试不是单元测试：it与数据库通信它不能与使用的其他测试并行运行，如注册表或文件系统还有什么？

问什么时候测试不是单元测试？
EN

回答 8

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问什么时候测试不是单元测试？EN

回答 8

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问什么时候测试不是单元测试？
EN