我加入了一个新团队，我在理解他们如何进行单元测试时遇到了问题。当我询问单元测试的编写地点时，他们解释说他们没有这样进行单元测试。
他们解释说，他们所谓的单元测试是他们实际检查他们在本地编写的代码，并且所有的点都是连接的。对我来说，这是集成测试，只是在本地测试代码。
我的印象是单元测试是为了验证代码的一小部分中的行为而编写的代码。例如，您可以编写单元测试以确保它返回正确的值，并对数据库进行适当的调用。使用像NUnit或MbUnit这样的框架来帮助你完成断言。
对我来说单元测试应该快速而快速。对我而言，您需要这些，以便您可以自动化它，并为您的应用程序提供大量测试，以确保它的行为符合您的预期。
有人可以澄清我或他们的误解吗？
答案 0 :(得分：7)
我曾经做过测试的地方并称之为单元测试。它让我想起了归因于亚伯林肯的一句话：
林肯：一条狗有多少条腿？其他人：4。
林肯：如果我们把尾巴叫做一条腿怎么办？其他人：那么它会有5个。
林肯：不，答案仍然是4.把一条腿拉到一条腿并不能成功。
答案 1 :(得分：5)
他们解释说他们称之为单元测试的是什么时候 实际上检查他们在本地编写的代码，以及所有的要点 正在联系。
这不是单元测试。这是一个代码审查。代码评论很好，但没有实际的单元测试，事情就会破裂。
单元测试涉及编写代码。具体而言，单元测试在一个单元上运行，该单元只是软件的一个类或组件。
如果受测试的类依赖于另一个类，并且您同时测试这两个类，则进行集成测试。集成测试很好。根据语言/框架，您可以对单元测试和集成测试使用相同的测试框架（例如，junit for java）。如果你有一个依赖项但是模拟或存根依赖，那么你有一个纯单元测试。
对我来说单元测试应该快速而快速。对我来说，你想要的 这些都可以使它自动化，并为您提供大量的测试 应用程序以确保它的行为与您的预期相同。
这基本上是正确的。开发单元测试的“快速和快速”取决于所测试内容的复杂程度以及编写测试的开发人员的技能。你肯定希望随着时间的推移建立一套测试，所以你知道什么时候因为代码库变得更复杂而出现问题。这就是测试如何使您的代码库更易于维护，告诉您在进行更改时停止运行的功能。
答案 2 :(得分：4)
您的队友没有进行单元测试。他们正在“通过你的裤子飞行”的发展。
答案 3 :(得分：3)
您的假设是正确的。
在没有单元测试的情况下进行项目（因为他们这样做，不要被愚弄）在最初的几周看起来不错：编写的代码更少，思考的架构更少，担心的问题更少。你可以看到代码工作正常，对吧？
但是，只要某人（其他人，甚至是原始编码人员）回到现有的代码片段来修改它，添加功能，或者只是了解它是如何工作的以及它到底做了什么，事情就会变得很多更有问题。在你意识到这一点之前，你将花费你的夜晚浏览日志文件并调试看起来像一个小功能，因为它需要与其他代码集成，而没有人确切知道它是如何工作的。你会恨你的工作。
如果不值得测试（使用实际的单元测试），那么首先编写代码是不值得的。每个试过没有单元测试和用单元测试进行编码的人都知道。拜托，请让他们改变主意。每次在某处检查一段未经测试的代码时，一只小狗就会死得很厉害。
另外，我应该说，稍后将测试添加到没有进行测试的项目中，比从一开始就构建测试和生产代码更加困难（很多）。测试不仅可以帮助您确保代码正常工作，还可以强制您做出正确的决策（即在接口上编码，松散耦合，控制反转等），从而提高代码质量。
答案 4 :(得分：2)
＆＃34;单元测试＆＃34; ！=＆＃34;单元测试＆＃34;。
编写单元测试是执行单元测试的一种特定方法。这是一个非常好的，如果你的单元测试写得很好，它可以在很长一段时间内给你很好的价值。但他们正在做的事情确实是单元测试。它只是那种在下次需要刻录相同代码时无法帮助您 的单元测试。这很浪费。
答案 5 :(得分：2)
添加我的两分钱，是的，这确实不是单元测试。恕我直言，单元测试的主要特点是它应该快速，自动化和隔离。您可以使用诸如RhinoMocks之类的模拟框架来隔离外部依赖项。
单元测试也必须非常简单和简短。理想情况下不超过屏幕长度。它也是软件工程中为数不多的几个地方之一，复制和粘贴代码可能比创建高度可重用和高度抽象的函数更好。简单性给予如此高优先级的原因是避免“谁看守望者”问题。您真的不希望遇到单元测试中存在复杂错误的情况，因为它们本身没有经过测试。在这里，您依靠极其简单和小巧的测试来避免错误。
单元测试的名称也应该是非常具有描述性的，再次遵循简单和自我记录的范例。我应该能够读取测试方法的名称并确切知道它在做什么。快速浏览代码应该可以准确地显示正在测试的功能以及是否有任何外部依赖项被模拟。
描述性测试名称也让您考虑整个应用程序。如果我查看整个测试运行，理想情况下只需查看运行的所有测试的名称，我就应该对应用程序的功能有一个很好的了解。