Questions tagged «unit-testing»

我正在努力掌握单元测试。 假设我们有一个模具，其默认面数可以等于6（但可以是4、5面，等等）： import random class Die(): def __init__(self, sides=6): self._sides = sides def roll(self): return random.randint(1, self._sides) 以下是有效/有用的单元测试吗？ 测试6面模具的1-6范围内的辊 测试6面模具的0卷 测试6面模具的7卷 测试3面模具的1-3范围内的辊 测试3面模具的0卷 测试一卷4的3面模具 我只是认为这些都是浪费时间，因为随机模块已经存在了很长时间，但是我认为如果随机模块得到更新（比如我更新了我的Python版本），那么至少我会被覆盖。 另外，在这种情况下，我是否还需要测试模具辊的其他变化，例如3，还是覆盖另一个已初始化的模具状态好吗？

18 python  unit-testing  tdd 

这些年来，我们已经为主要程序建立了大量的单元测试。几千。问题在于，由于测试太多，我们没有明确的想法。这是一个问题，因为我们不知道测试的弱点（或重复的地方）。 我们的应用程序是一个报告引擎。因此，您可以有一个模板用于测试解析（我们是否读取了所有表属性），合并数据（是否在合并中保留了正确的表属性），格式化了最终页面（表格是否正确放置在页面上？ ）和/或输出格式（创建的DOCX文件正确）。 除此之外，我们需要测试。在表格单元格周围填充（我们使用Word，Excel和PowerPoint进行报表设计）。我们必须测试跨分页符的填充情况，对于单元格内的表，垂直合并的单元格，水平合并的单元格，垂直和水平合并的单元格（其中包含一个表，内部表中的垂直和水平合并的单元格），该表跨页中断。 那么该测试属于哪一类？表格填充，分页符，嵌套单元格，垂直合并的单元格，水平合并的单元格或其他内容？ 以及我们如何记录这些类别，命名单元测试等？ 更新：许多人建议使用覆盖率工具来验证我们是否具有完整覆盖率。不幸的是，这在我们的案例中用途有限，因为这些错误往往是由于特定的组合所致，因此已经对所有代码进行了测试，但没有进行组合。 例如，昨天有一个客户在其模板（Word文档）的forEach循环的末尾开始了Word书签，并在下一个forEach循环的末尾结束了它。所有这些都使用了针对其进行了单元测试的代码，但是我们没有想到将模板扩展为书签的组合从开始开始25次，然后结束10次（两个forEach循环具有不同的行数）。

18 unit-testing  project-structure 

在基于医疗软件案例的TDD培训期间，我们实现了以下故事：“当用户按下保存按钮时，系统应添加患者，添加设备并添加设备数据记录”。 最终的实现将如下所示： if (_importDialog.Show() == ImportDialogResult.SaveButtonIsPressed) { AddPatient(); AddDevice(); AddDeviceDataRecords(); } 我们有两种方法可以实现它： 调用了三个测试，每个测试都验证一个方法（AddPatient，AddDevice，AddDeviceDataRecords） 一种验证所有三种方法的测试称为 在第一种情况下，如果if子句条件发生错误，则所有三个测试均将失败。但是在第二种情况下，如果测试失败，我们不确定到底是什么错误。您会选择哪种方式。

18 unit-testing  tdd 

我正在做单元测试。 我正在尝试测试一个功能。 我从测试组件中调用它。但是，我想，如果远程功能不能处理异常，那么我的测试器组件也将获得异常。 那么我应该担心在测试器组件中出现异常吗？ 谢谢。 编辑： PS： 抛出错误是件好事，但仅对其他功能有用，直到最后一个选择才对最终用户有效！ 天哪，我写了一个编程报价！

18 testing  unit-testing  exceptions 

按照目前的情况，这个问题不适合我们的问答形式。我们希望答案会得到事实，参考或专业知识的支持，但是这个问题可能会引起辩论，争论，民意调查或扩展讨论。如果您认为此问题可以解决并且可以重新提出，请访问帮助中心以获取指导。 7年前关闭。 我曾计划研究并将单元测试应用到我的代码中，但是在与我的同事交谈之后，他们中的一些人向我暗示这是没有必要的，并且几乎没有好处。他们还声称只有很少的公司实际使用生产软件进行单元测试。 我很好奇人们在工作中如何应用单元测试，以及使用它们会获得什么好处，例如更好的代码质量，减少长期的开发时间等。

18 unit-testing 

已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗？更新问题，使其仅通过编辑此帖子来关注一个问题。 4个月前关闭。 如果您一直喜欢单元测试，那对您有好处！但是对于那些不是天生喜欢它的人来说，您如何使这项任务变得更加愉快呢？ 这不是“什么是正确的单元测试方法”的问题。我只是想知道一些个人技巧，这些技巧可以减少编写单元测试的乏味（我敢说）。

18 productivity  unit-testing 

我正在研究一个列表比较器，以帮助根据客户的非常特定的要求对搜索结果的无序列表进行排序。需求要求使用重要性规则按以下规则排序相关性算法： 姓名完全匹配 搜索词中所有单词的名称或结果的同义词 搜索查询中某些单词的名称或结果的同义词（％降序） 说明中搜索查询的所有单词 说明中搜索查询的某些单词（降序排列） 最后修改日期降序 该比较器的自然设计选择似乎是基于2的幂的得分排名。次要重要规则的总和永远不会与重要性较高的规则的正比匹配大。这可以通过以下得分来实现： 32 16 8（基于决断百分比下降的次决胜局得分） 4 2（基于降低百分比的次决胜局得分） 1个 本着TDD的精神，我决定首先进行单元测试。对于每个唯一方案都有一个测试用例，至少要有63个唯一测试用例，而不考虑规则3和5上的辅助抢断逻辑的其他测试用例。这似乎太过分了。 实际的测试实际上会更少。根据实际规则本身，某些规则可确保较低的规则将始终为真（例如，当“所有搜索查询词都出现在说明中”时，规则“某些搜索查询词会出现在说明中”将始终为真）。写下每个测试用例的努力水平仍然值得吗？在谈论TDD中100％的测试覆盖率时，这通常是要求的测试级别吗？如果不是，那么什么是可接受的替代测试策略？

18 algorithms  unit-testing  tdd 

“为什么您可以肯定地知道为什么您的测试很好呢？有时Jester告诉我我的测试是密闭的，但是有时发现的变化却是突然的。强烈推荐。”-肯特·贝克（Kent Beck） 但是我看到在stackoverflow中甚至没有一个名为“ Jester ” 的标签。那么，对于Jester的现代替代品是什么？除了从Cobertura和Clover等工具的代码覆盖范围中找到统计信息之外，如何确保编写的单元测试牢不可破？

18 java  unit-testing  code-quality  tdd 

我想将测试代码与产品一起提供。具体来说，提供一个选项，以便拥有我们程序副本的任何人都可以单击“自检”按钮或在命令行上通过--self-test并运行完整的单元| 集成测试。 我主要是想这样做，以帮助调试在现场发现的问题，因此，当最终用户收到错误报告时，“并且这三项测试在我的计算机上都失败了”，这有可能会为它提供支持。我希望手动测试仪能够运行该单元| 集成测试。 但是，团队的测试认为测试代码不是生产代码，因此不应发货。因为大多数开源项目都附带了一个测试套件，所以我并没有真正理解这个论点。在封闭的软件中，这确实不寻常。 我想为论证的任何方面提供证据或轶事。我已经最好地猜测了哪个堆栈交换站点最合适，但是如果这不合适，请告诉我。

17 c++  unit-testing  testing 

我有许多业务逻辑方法，用于存储和检索（通过过滤）对象以及来自缓存的对象列表。 考虑 IList<TObject> AllFromCache() { ... } TObject FetchById(guid id) { ... } IList<TObject> FilterByPropertry(int property) { ... } Fetch..并Filter..会调用AllFromCache它来填充缓存，如果不存在则返回，如果存在则从其返回。 我通常回避对这些单元进行测试。针对此类结构进行单元测试的最佳实践是什么？ 我考虑过在TestInitialize上填充缓存，并在TestCleanup上删除缓存，但这对我来说并不对，（很可能）。

17 unit-testing  caching 

我在C ++中的OpenGL之上编写游戏和随附的图形引擎。我也是良好的编码过程和自动化测试的粉丝。图形输出+测试似乎几乎是不混溶的，因为输出通常仅是可视的，或者非常注重视觉。 例如，想象一下按字节分析渲染到屏幕上的原始图像流-您需要与之比较的测试数据，这很难创建/获取，并且通常渲染的图像在屏幕上并不相同。在不同时间运行时的字节级别-算法中的微小变化将完全破坏该方法。 我正在考虑创建一个可视化的单元测试套件，在其中基本上可以渲染不同的测试场景，显示诸如阴影贴图，动画等之类的内容。作为CI的一部分，这些场景随后将被渲染为视频。具有不同指标的文件（或可能将其保留为可执行文件）。这仍然需要对视频文件进行手动检查，但至少会实现某种程度的自动化和标准化。 你怎么看？我希望有更好的方法？

17 c++  unit-testing  graphics  opengl  test-automation 

关闭。这个问题是题外话。它当前不接受答案。 想改善这个问题吗？ 更新问题，使它成为软件工程堆栈交换的主题。 6年前关闭。 是否有任何使用测试驱动的开发开发的开源应用程序可以作为良好的单元测试应该如何工作的模型？ 我更喜欢在C＃和.NET中查看示例。（请注意，我提到的是应用程序，而不仅仅是库。） 我是一个中层程序员，他真的想相信并实践TDD。我在日常工作中使用的应用程序非常复杂-大约一百万行代码-我很想介绍更多的单元测试。我们已经进行了一些单元测试，但是我在TDD上所做的工作以及已经在测试中的代码的工作都没有令人鼓舞。 以我公认的有限经验，TDD似乎以去耦的名义鼓励了很多复杂性。应用程序中难以测试的部分（巧合地往往很关键）被推向外围，进入了可能会或可能永远不会编写的集成测试领域。（我在这里想到了通常的可疑对象，文件系统访问，从数据库中添加对象，异步Web调用等） 被测试的代码往往涉及对象之间的大量协作，也许还涉及一些简单的流逻辑，所有这些都发生在内存中，并且如果不必完全分离所有对象，则可以用更简单，更易理解的方式编写供测试用。 我了解模拟依赖项等的技巧，但是根据我的经验，大量使用模拟会导致非常脆弱的测试。如果我看到许多测试变成红色的第一个直觉是：“好，现在我必须修复所有模拟程序”，那么我的测试就成了阻力，而不是安全网。 我正在努力克服这一精神障碍，在其中，我正在阅读Michael Feathers的书《有效地使用Legacy Code》。我希望它能告诉我一些我所缺少的东西。 我还想研究一些具有良好代码覆盖率的.NET应用程序，例如内容管理系统或CRUD应用程序。Bob叔叔谈论的FitNesse测试框架是我可能要看的东西，但是很高兴看到用我最熟悉的语言编写的东西。 任何建议或智慧的话，将不胜感激。

17 unit-testing  tdd 

背景：我正在考虑通过为我一直在研究的模块创建一些单元测试的概念来向同事介绍单元测试的概念。它的要求最近发生了变化，并且需要更多的抽象/交互，因此，这似乎是开发一套测试套件的好方法，该套件可以“证明”它的工作原理，而无需手动在应用程序周围戳戳。 但是，问题在于该模块依赖于不可模拟的外部因素，即PDF和XSL。基本上，我从数据库中读取XML并对其进行XSL转换，然后使用称为ABCPDF的库将其转换为PDF。然后将此PDF与基于静态模板的另一个PDF合并。我知道我可以测试XML并确保值正确，但是许多潜在的错误和问题都与最终文档的实际显示有关-例如，细节，例如包裹了多长的文本字符串，某些HTML区域位于甚至可以测试这些东西（我意识到这些可能是集成测试，或者..我忘记了其名称的第三种测试[不是验收测试，另一种]而不是单元 测试），因为据我所知，我无法轻松地模拟出一个PDF，除非创建它，然后回读或创建一个HTML字符串（即转换后的XML），然后手工解析它以检查其中是否存在某些表格单元格与其他表格单元的关系。 在这种情况下，我应该只专注于单元测试以确保信息正确，并且可以创建 PDF或合并它们，或者采取其他任何措施来针对实际的显示问题进行手动测试吗？

17 unit-testing 

我们最近在我们的应用程序中发现了一个特定于区域设置的问题，尽管很容易解决（一旦我们弄清楚了发生了什么），但它使我的团队正在考虑这方面的单元测试实践。 我们希望尽早发现这些问题，最好是在客户发现它们之前，并且我们希望将来避免重新引入特定于区域设置的错误，但是在至少一种其他文化中复制每个单元测试似乎很多高架。 您如何或将如何进行多语言环境单元测试？

17 unit-testing  localization 

假设我们有一个大型企业级应用程序，而没有任何单元/功能测试。由于非常紧迫的期限，因此在开发过程中没有测试驱动的开发过程（我知道我们永远不能在不确定的情况下承诺任何紧迫的期限，但是已经完成了！） 既然所有的截止日期都过去了，事情变得平静了，每个人都同意将我们转变成一个富有成效的基于TDD / BDD的团队...是的！ 现在的问题是关于我们已经拥有的代码：（1）停止大多数开发并从头开始编写所有可能的测试用例还是可以的，尽管一切都可以很好地进行（尽管！）。 ？或（2）最好等待一些不好的事情发生，然后在修复过程中编写新的单元测试，或者（3）甚至忘记以前的代码，而只为新代码编写单元测试，并将所有内容推迟到下一个主要重构中。 有几个好的，如相关的文章这一个。考虑到我们的时间非常有限，还有许多其他项目/作品正在等待我们，我仍然不确定是否值得为此进行投资。 注意：这个问题正在解释/想象开发团队中一个完全尴尬的情况。这与我或我的任何同事无关；这只是一个假想的情况。您可能会认为这种情况永远都不会发生，否则开发经理会造成这种混乱！但是无论如何，已经完成了。如果可能的话，请不要仅仅因为您认为这永远不会发生而投票。

17 unit-testing  testing  tdd  bdd  acceptance-testing