Questions tagged «testing»

考虑一下： public function polynominal($a, $b, $c, $d) { return $a * pow($x, 3) + $b * pow($x, 2) + $c * $x + $d; } 假设您为上述功能编写了各种测试，并向自己和其他人证明“它可以工作”。 为什么不删除这些测试，然后过上幸福的生活呢？我的观点是，某些功能在被证明可以正常工作后，无需对其进行连续测试。我正在寻找状态的对立点，是的，这些功能仍然需要测试，因为：...或者是的，这些功能不需要进行测试...

36 php  unit-testing  testing  tdd 

我知道这听起来很像已经提出的其他问题，但实际上略有不同。似乎通常认为程序员并不擅长于测试应用程序。例如： Joel谈软件- 没有测试人员的前五（错误）原因（强调我的意思） 甚至不要想告诉大学CS毕业生他们可以为您工作，但是“每个人都必须在QA工作一段时间，然后再进行编码”。我已经看到了很多。程序员不能成为优秀的测试人员，并且您将失去一个优秀的程序员，而后者很难被替换。 在这个问题中，最受欢迎的答案之一是（再次强调）： 开发人员可以成为测试人员，但他们不应该成为测试人员。开发人员倾向于无意/无意识地避免以可能破坏应用程序的方式使用该应用程序。那是因为他们编写了它，并且主要以应使用的方式对其进行了测试。 所以问题是程序员不好测试吗？有哪些证据或论点支持这一结论？程序员是否只擅长测试自己的代码？有没有证据表明程序员实际上擅长测试？ 我所说的“测试”是什么意思？我并不是说单元测试或任何被软件团队用来编写软件的方法论的一部分。我的意思是在构建代码并将其部署到软件团队称为“测试环境”的任何位置之后使用的某种质量保证方法。

36 testing  qa 

假设我有一个函数（用Ruby编写，但每个人都应该理解）： def am_I_old_enough?(name = 'filip') person = Person::API.new(name) if person.male? return person.age > 21 else return person.age > 18 end end 在单元测试中，我将创建四个测试以涵盖所有场景。每个Person::API对象都将使用带有stubbed方法male?和的模拟对象age。 现在谈到编写集成测试。我认为不应再嘲笑Person :: API。因此，我将创建完全相同的四个测试用例，但不模拟Person :: API对象。那是对的吗？ 如果是，那么编写单元测试的意义何在？如果我可以编写使我更有信心的集成测试（因为我在处理真实对象，而不是存根或模拟对象）？

36 unit-testing  testing  ruby  integration-tests 

我目前正在从事一个相当大的项目，并且我已经使用JUnit和EasyMock相当广泛地进行了单元测试功能。我现在对我应该担心的其他类型的测试感兴趣。作为开发人员，我有责任担心诸如功能测试或回归测试之类的事情吗？是否有很好的方法将这些以可用的方式集成到Maven / Ant / Gradle等工具中？这些是否更适合测试人员或BA？我还缺少其他有用的测试类型吗？

35 testing 

我应该在应用程序中为复杂的正则表达式编写单元测试吗？ 一方面：它们易于测试，因为输入和输出格式通常很简单且定义明确，而且它们往往变得如此复杂，因此对它们的测试特别有价值。 另一方面：它们本身很少是某个单元界面的一部分。最好只测试接口，然后以隐式测试正则表达式的方式进行操作。 编辑： 我同意布朗博士的意见，他在评论中指出这是内部组件单元测试的特例。 但是正则表达式作为内部组件具有一些特殊特征： 没有真正的单独模块，单行正则表达式可能非常复杂。 正则表达式将输入映射到输出而没有任何副作用，因此真正易于单独测试。

34 unit-testing  testing  regular-expressions 

我正在使用以下系统： Network Data Feed -> Third Party Nio Library -> My Objects via adapter pattern 最近，我们遇到了一个问题，即我更新了所使用的库的版本，这尤其导致时间戳（第三方库返回该时间戳long）从时期后的毫秒数更改为时期后的毫微秒。 问题： 如果编写模拟第三方库对象的测试，则如果我对第三方库的对象犯了错误，则我的测试将是错误的。例如，我没有意识到时间戳会改变精度，这导致需要更改单元测试，因为我的模拟返回了错误的数据。这不是库中的错误，它的发生是因为我错过了文档中的某些内容。 问题是，我无法确定这些数据结构中包含的数据，因为如果没有真实的数据馈送，我将无法生成真实的数据。这些对象又大又复杂，并且其中包含许多不同的数据。第三方库的文档很差。 问题： 如何设置测试以测试此行为？我不确定我可以在单元测试中解决此问题，因为测试本身很容易出错。另外，集成系统又大又复杂，容易遗漏一些东西。例如，在上述情况下，我已经在几个地方正确地调整了时间戳记处理，但是我错过了其中之一。在我的集成测试中，该系统似乎在做正确的事情，但是当我将其部署到生产环境（具有大量数据）时，问题变得很明显。 我目前没有集成测试过程。测试本质上是：尝试保持单元测试良好，在出现问题时添加更多测试，然后部署到我的测试服务器并确保一切正常，然后部署到生产中。这个时间戳问题通过了单元测试，因为模拟创建错误，然后通过了集成测试，因为它没有引起任何直接的，明显的问题。我没有质量检查部门。

34 testing  object-oriented-design  development-process  mocking  adapter 

我刚刚在Web应用程序中实现了一个缓存层，现在我想知道QA应该如何测试它，因为缓存对用户是透明的。 我的一个想法是将登录记录在调用填充缓存的代码的方法中，并记录何时从缓存中提取对象以及何时需要从数据库中重新创建对象，然后测试人员可以查看日志以查看是否，例如，每隔10分钟就会从数据库中重新加载某个对象，而不是每一次页面浏览。 但是有人可以针对这种情况提出一些更好的做法吗？

33 testing  caching 

我是正在研究BE（CS）的学生，我的问题如下： 是否需要在软件领域进行测试？ 如果我们非常谨慎地创建软件，那么为什么要进行测试？ 经过测试，我们是否可以确定已经实现了该目标（产品/软件按预期工作），因为我们已经对其进行了测试？可能吗？ 我的问题：是否需要测试软件？

33 testing  quality  validation  qa  verification 

我一直看到建议，我们应该首先编写单元测试，然后再开始编写代码。但是我觉得（对我来说）走另一条路要舒适得多-编写代码，然后进行单元测试，因为在编写实际代码后，我觉得我们更加清楚了。如果我先编写代码然后进行测试，那么即使我将精力集中在创建可测试的设计上，也可能需要稍稍更改一下代码以使其可测试。另一方面，如果我先编写测试，然后编写代码，则当代码成形时，测试将非常频繁地更改。 正如我看到的有关开始编写测试然后继续进行编码的大量建议一样，如果我以其他方式进行编写，然后编写单元测试，则有什么缺点呢？

33 testing  unit-testing  code-quality  tdd 

随着我目前的Java项目变得越来越大，我感到同样需要在代码的多点插入调试输出。 为了适当地启用或禁用此功能，具体取决于测试会话的打开或关闭，我通常private static final boolean DEBUG = false在测试要检查的类的开头放置a ，然后以这种方式简单地使用它（例如）： public MyClass { private static final boolean DEBUG = false; ... some code ... public void myMethod(String s) { if (DEBUG) { System.out.println(s); } } } 等等。 但这并不能使我感到高兴，因为它当然有效，但是如果您不仅仅盯着其中的几个，可能会有太多的类将DEBUG设置为true。 相反，我（就像-我认为-许多其他人一样）不希望将整个应用程序置于调试模式，因为输出的文本数量可能很庞大。 那么，有没有一种正确的方法来处理这种情况，或者最正确的方法是使用DEBUG类成员？

32 java  testing  logging  debugging 

我在一家中型公司（拥有150名员工，约有10名规模的工程团队）工作，我的大多数项目都涉及与实验室设备（示波器，光谱分析仪等）的接口，以实现半自动化测试应用。我遇到了几种不同的情况，由于我不再或从来没有可用的硬件设置，因此无法有效地排除故障或测试新代码。 示例1：使用台式型传感器独立运行10-20个“老化”过程的设置-我能够获得一个这样的传感器进行测试，并且偶尔可以花一秒钟来模拟与之连接的所有方面多个设备（搜索，连接，流式传输等）。 最终出现了一个错误（最终最终归结于设备固件和驱动程序中），仅用一个单元就很难准确地再现该错误，但是当同时使用10-20个此类设备时，该错误接近“显示停止器”的水平。这仍未解决，仍在进行中。 示例2：需要昂贵的光谱分析仪作为其核心组件的测试。该设备相当老旧，是一家制造商遗留下来的，后者被一家较大的公司收购，并且基本上已经解散，并且它的唯一文档是冗长的（且内容不丰富的）文档，翻译起来似乎不好。在最初的开发过程中，我能够将设备保持在桌面上，但现在在24/7多周的测试中，无论是在物理上还是在计划中都将其捆绑在一起。 当错误显示出与设备相关或无关的错误时，我经常需要麻烦测试应用程序外部的代码并将其装入，或者盲目编写代码并尝试在两次运行之间的某个测试时间内进行压缩，程序逻辑要求OSA和其余测试硬件都安装到位。 我想我的问题是我应该如何处理？我可能会花一些时间来开发设备模拟器，但是弄清楚开发估算值将使它比大多数人想像的更多。它也可能无法准确地重现所有问题，而且很少有人看到同一设备在这里两次使用过。我可以在单元测试方面变得更好...等等...我也可以大声地谈论这个问题，并让其他人理解将需要暂时的延迟，这不只是研究和开发的头痛，而是通常被认为是在开玩笑当投入制造业时。

30 programming-practices  testing  hardware  test-automation 

假设我有一个从基类Employee派生的类Manager，并且该Employee有一个由Manager继承的方法getEmail（）。我是否应该测试经理的getEmail（）方法的行为实际上与员工的行为相同？ 在编写这些测试时，其行为将是相同的，但是当然在将来的某个时候，有人可能会重写此方法，更改其行为，从而破坏我的应用程序。但是，从根本上测试是否存在干预代码似乎有些奇怪。 （请注意，在创建/覆盖Manager :: getEmail（）之前，测试Manager :: getEmail（）方法不会提高代码覆盖率（或其他任何代码质量指标（？））。 （如果答案是“是”，则有关如何管理基类和派生类之间共享的测试的一些信息将很有用。） 问题的等价表述： 如果派生类从基类继承方法，则如何表达（测试）是否期望继承的方法： 行为与现在的基础完全相同（如果基础的行为发生了变化，则派生方法的行为不会发生变化）； 始终具有与基类完全相同的方式（如果基类的行为发生变化，派生类的行为也发生变化）；要么 但是，它要表现出来（您不必关心此方法的行为，因为您从不调用它）。

30 testing  inheritance 

我想向我的同事介绍单元测试（和一般测试）的概念；现在根本没有测试，通过UI实际执行任务以查看期望的结果来测试事物。就像您想象的那样，代码与确切的实现紧密耦合-甚至导致代码应该放在一个类中并在整个系统中重复使用，并且跨方法进行复制和粘贴。 由于需求的变化，我被要求修改我先前编写的模块，该模块相当松散地耦合在一起（虽然不尽如人意，但在无需引入许多其他概念的情况下，我可以做到最好）。我决定在修订后的代码中包含一套单元测试，以“证明”它可以按预期工作，并演示测试的工作方式。我没有遵循真正的TDD，因为已经编写了一些代码，但是我希望遵循一些TDD概念来创建新代码。 现在，我不可避免地会被问到，为什么要花我一两天以上的时间来编写代码，因为我要与之交互的部分已经存在于系统中（尽管没有任何测试并且非常紧密耦合），当我检查其中的代码时，系统将询问我这个“测试”项目是什么。我可以解释测试的基础知识，但是我无法以其他人会理解的方式解释实际好处（因为他们认为测试需要您自己运行应用程序，因为通常实际的UI在确定功能是否“有效”时很重要“ 或不）。他们不理解松散耦合的思想（显然没有松散耦合的事实；在我编写的代码之外甚至没有任何接口），因此尝试将其用作收益可能会给我带来“恩？” 外观，再也不必放松一些现有模块，并可能引入某种IoC容器，这就像浪费时间，而不是“编程”。 有人对我如何指向此代码有任何建议，并说“我们应该开始创建单元测试”而不会屈服于任何一个居高临下的条件（例如，“编写测试会迫使您编写良好的代码。”这可能意味着代码除非是我的坏人），还是没有浪费时间却没有增加任何实际价值？

30 testing  unit-testing  teamwork 

一年多以前，我很幸运能够休息9个月。我决定在那段时间里磨练自己的C＃技能。我开始从事许多项目，并强迫自己遵循TDD。 这是一个相当启发的过程。 刚开始时很难，但是随着时间的流逝，我学会了如何编写更多可测试的代码（事实证明，这往往是更多的SOLID代码），并且在此过程中，我还提高了OO设计技巧。 现在，我回到了工作岗位，并且注意到了一些奇怪的事情。 我宁愿不遵循TDD。 我发现TDD会使我慢下来，实际上使设计干净的应用程序更加困难。 相反，我采用了一种（完全）不同的方法： 挑选垂直的作品 开发功能正常的原型 重构直到一切都变得整洁 请欣赏一下我编写的精美的SOLID和可测试的代码。 您可能已经注意到，第1步不是“定义我的测试目标的公开表面”，而第2步不是“在所述公开表面上测试耶稣”。您可能还注意到，所有步骤都不涉及测试。我正在编写可测试的代码，但是我尚未对其进行测试。 现在，我想说明一下，我实际上并没有进行任何类型的测试。我正在编写的代码有效。它有效，因为我正在手动测试它。 我还想明确指出，我也没有提到所有自动化测试。这是我的过程与众不同的地方。这就是为什么我问这个问题。 TDD理论上。不在实践中。 我的过程有所发展，我在TDD和没有发现我认为非常有效且也相当安全的测试之间取得了平衡。内容如下： 在考虑到测试的情况下实现工作的垂直工作，但是不要编写任何测试。 如果在路上（例如，一个月后），该切片需要修改 编写单元测试，集成测试，行为测试等，以确保工作片段正确无误 修改代码 如果该切片不需要修改， 没做什么 通过简单地将编写测试的负担从编写代码之前转移到修改代码之前，我已经能够生产出更多的工作代码。而且，当我确实着手编写测试时，我编写的测试数量要少得多，但是覆盖的范围却差不多（投资回报率更高）。 我喜欢这个过程，但是我担心它可能无法很好地扩展。它的成功取决于开发人员在更改测试之前勤于编写测试。这似乎是一个很大的风险。但是，TDD具有相同的风险。 那么，我该死[BT] DD，还是这是一种实用的编码和测试的常见形式？ 我想继续这样工作。从长远来看，我该怎么做才能使该过程正常运行？ 注意： 我是项目的唯一开发人员，我负责所有工作：需求收集，设计，架构，测试，部署等。我怀疑这就是我的流程正常运行的原因。

29 testing  development-process 

纠正错误时，鼓励我在这里工作，首先编写一个因给定错误而失败的测试，然后修复代码，直到测试通过。这遵循TDD惯例，应该被认为是很好的惯例，但是我注意到它往往会产生与实现非常接近的神秘测试。 例如，我们在发送作业，达到某个状态，中止并重试时遇到问题。为了重现此错误，编写了一个包含线程同步的大量测试，其中包含大量的模拟和其他东西。它确实可以完成工作，但是现在我正在重构代码，我发现删除此庞然大物非常诱人，因为要适应新设计，确实需要很多工作（再次）。它只是在单个特定情况下测试一个小功能。 因此，我的问题是：如何测试难以重现的错误？您如何避免创建测试实现的东西，并损害重构和可读性？

29 testing  tdd