Questions tagged «unit-testing»

单元测试是一种测试源代码的各个单元以确定它们是否适合使用的方法。

3
使用BDD时如何使用单元测试？
我试图了解BDD。我读过一些文章，据我了解，BDD是TDD的“下一步”。我之所以这么说是因为我发现两者非常相似，并且正如我在本文中所读到的那样，BDD是TDD的改进。太好了，我真的很喜欢这个主意。 我没有想到一个实用的观点：有一个.feature文件，BA将在其中写入系统将具有的所有预期行为。作为一名学士学位，他不知道系统的构建方式，因此我们将编写如下内容： +方案1：帐户已入帐+ 鉴于该帐户已贷记 而且卡是有效的 而且分配器中有现金 当客户要求现金时 然后确保帐户已借记并确保已分配现金 并确保卡已归还 好的，这很不错，但是系统中的许多部分都可以进行协作，以便可以实现（例如Account obj，Dispenser obj，Customer obj等）。在我看来，这就像一个集成测试。 我想进行单元测试。我如何测试检查分配器是否有钱的代码？还是分配了现金？还是该帐户在需要时借记？ 如何将单元测试与“ BA创建”测试混合？
17 unit-testing  bdd 
2
从外部文件加载或不加载用于单元测试的数据
在进行单元测试时，我经常会辩论自己要馈入的数据量，并期望从被测单元中回来，我应该将它们包含在实际的测试文件中。 我不断努力的权衡是： 如果测试的很大一部分（以代码量计）由输入和输出数据组成，那么似乎很难实际读取测试，但是我可以很容易地看到实际的输入和输出。 如果我从文件中加载测试数据，则可以轻松地对可能的数据输入进行一堆测试，轻松地将测试数据重复用于多个测试，但是我必须离开源代码来查看另一个文件，以查看输入的确切含义。 。 其中之一是反模式吗？
5
在TDD中，如果我编写的测试用例在不修改生产代码的情况下通过了，那意味着什么？
这些是Robert C. Martin的TDD规则： 除非要通过失败的单元测试，否则不允许编写任何生产代码。 您不得编写任何足以使单元测试失败的单元测试。编译失败就是失败。 您不能编写任何足以通过一项失败的单元测试的生产代码。 当我编写一个看似值得但未更改生产代码的测试通过时： 这是否表示我做错了？ 如果可以帮助，将来是否应该避免编写此类测试？ 我应该将该测试留在那里还是将其删除？ 注意： 我在这里试图问这个问题：我可以从通过单元测试开始吗？ 但是直到现在我还不能很好地阐明这个问题。
5
为什么将单元测试专用方法视为不良做法？
内容： 我目前正在使用Python进行一个小项目。我通常使用一些公开的方法来构造我的类，这些方法已记录在案，但主要处理高级概念（类的用户应了解和使用的内容），以及一堆隐藏的（从下划线开始）负责方法的类。复杂或低级别的处理。 我知道测试对于确保代码的信心并确保以后进行的任何修改都不会破坏以前的行为至关重要。 问题： 为了在受信任的基础上构建更高级别的公共方法，我通常会测试私有方法。我发现查找代码修改是否已引入回归以及在何处更容易。这意味着这些内部测试可能会因次要修订而中断，并且需要修复/替换 但是我也知道，单元测试私有方法至少是一个有争议的概念，或者更经常被认为是不好的做法。原因是：仅应测试公共行为（参考） 题： 我确实关心以下最佳做法，并希望了解： 为什么在私有/隐藏方法上使用单元测试不好（有什么风险）？ 当公共方法可以使用低级和/或复杂处理时，最佳实践是什么？ 精度： 这不是一个如何的问题。Python没有真正的隐私概念，隐藏的方法根本没有列出，但是当您知道它们的名称时就可以使用 我从没学过编程规则和模式：我的上一堂课是80年代的...我主要通过尝试和失败以及在Internet上的引用来学习语言（多年来，Stack Exchange是我的最爱）
6
按需求或方法划分单元测试
首先，对标题表示歉意，我想不出最简单的解释方法！ 我有一个要为其编写单元测试的方法。我将使其保持相当通用，因为我不想讨论该方法的实现，而只是讨论它的测试。方法是： public void HandleItem(item a) { CreateNewItem(); UpdateStatusOnPreviousItem(); SetNextRunDate(); } 因此，此类有一个公共方法，然后调用一些私有方法来执行逻辑。 因此，在编写单元测试时，我想检查所有三件事。因为它们都在同一运行中被调用，所以我认为我可以将其作为一项测试： public void GivenItem_WhenRun_Thenxxxxx { HandleItem(item); // Assert item has been created // Assert status has been set on the previous item // Assert run date has been set } 但我认为我也可以将其编写为三个单独的测试： public void GivenItem_WhenRun_ThenItemIsCreated() { HandleItem(item); } public …
16 c#  unit-testing 
3
您如何测试仅用于查询外部API但API使用复杂查询语法的函数？
唯一的逻辑是外部API的查询语法。我不想测试它是否查询api，我想测试它是否以返回正确数据的方式查询它。例如，一些伪代码： function retrieve_related_data(id) { query = "[potentially long, syntactically complex query that uses param id to get some data]"; results = api_wrapper.query(query); return results; } 一个由API组成的更具体的示例： function retrieveLifeSupportingObjectsWithinRegion(id) { query = " within region(" + id + ") as r find objects matching hydration>0 and temp_range has 75 send name, …
4
如何减少用较大的对象模型包装第三方库的手动工作？
就像2012年这个问题 的作者和2013年这个问题的作者一样，我有一个第三方库，需要对其进行包装以正确测试我的应用程序。最高答案指出： 您始终希望将第三方类型和方法包装在接口后面。这可能是乏味且痛苦的。有时，您可以编写代码生成器或使用工具来执行此操作。 就我而言，该库用于对象模型，因此具有大量的类和方法，这些类和方法需要包装才能使该策略成功。除了“繁琐而痛苦”之外，这也成为测试的硬障碍。 自提出这个问题以来的四年中，我知道隔离框架已经走了很长一段路。我的问题是：现在是否存在一种更简单的方法来实现完全包装第三方库的效果？我如何摆脱这一过程中的痛苦并减少手工工作？ 我的问题不是我最初链接的问题的重复，因为我的问题是减少手工包装的工作。这些其他问题仅询问包装是否有意义，而不是如何减少工作量。
4
如何为GUI编写可维护的而不是脆弱的单元测试？
我尝试为我的GUI应用程序编写UI单元测试，但我遇到的问题是，尽管在我最初编写它们时它们可以很好地工作，但是它们却很脆弱，并且每当设计更改时（即经常）它们就会损坏。我正在努力寻找一套指导方针，以使我能够进行GUI的可维护单元测试。 就目前而言，我发现的一件事是，测试表明“该组件应在某处显示其输入数据”是很好的（并且使用HTML非常容易）。检查组件特定部分的特定状态的测试通常很脆弱。试图遵循用户行为和基本业务逻辑（这是最重要的部分）的测试，如单击-单击-单击-预期，通常会变得很脆弱。如何编写好的测试？ 更精确地说，我想了解一些模式有什么可我在UI测试，不完全是如何对其进行测试。命名约定和固定标识符很好，但是不能解决核心问题，即GUI发生了很大变化。我想测试最不可能改变的行为。如何找到合适的东西进行测试？
6
从TDD的角度来看，如果我针对实时端点而不是模拟进行测试，那我是一个坏人吗？
我虔诚地遵循TDD。我的项目通常具有有意义的测试用例，测试覆盖率可达85％或更高。 我使用HBase进行了大量工作，而主要的客户端接口HTable实在令人难以接受。与编写使用实时端点的测试相比，编写我的单元测试要花3到4倍的时间。 从哲学上讲，我知道使用模拟的测试应优先于使用实时端点的测试。但是模拟HTable是一个严重的难题，我不确定它相对于针对实时HBase实例进行测试是否具有很多优势。 我们团队中的每个人都在其工作站上运行一个单节点HBase实例，而我们的Jenkins机器上运行着一个单节点HBase实例，因此这不是可用性问题。实时端点测试显然比使用模拟的测试花费更长的时间，但是我们并不在乎。 现在，我为我的所有类编写了实时端点测试和基于模拟的测试。我很想抛弃模拟游戏，但我不希望结果因此而下降。 你们怎么想
1
如何对REST Web服务进行单元测试？
我是单元测试的新手，我有一个REST Web方法，它仅调用DB并填充DTO。伪代码是 public object GetCustomer(int id) { CustomerDTO objCust = //get from DB return objCust; } 我的疑问是如何编写针对这些方法的测试以及要包括的测试类型（集成/单元）。对于单元测试，是否需要命中数据库。如果是这样，并且我传递了一个客户ID并执行了一些断言，则数据可能会更改，最终导致失败。 我想我在这里缺少了解这些概念的内容。
2
软件测试技术或类别
很难说出这里的要求。这个问题是模棱两可，含糊，不完整，过于宽泛或夸张的，不能以目前的形式合理地回答。如需帮助澄清此问题以便可以重新打开， 请访问帮助中心。 8年前关闭。 您知道哪种软件测试？我听说过测试驱动开发，单元测试等，但是不了解它们的重要性和差异。例如，为什么我们要使用回归测试或验收测试。他们提供什么优势？
6
从过程代码转换为面向对象的代码
我一直在阅读“有效地使用遗留代码和清除代码”，其目的是学习有关如何开始清除大型ASP.NET Webforms应用程序的现有代码库的策略。 该系统自2005年起问世，此后进行了许多增强。最初，代码的结构如下（并且仍然在很大程度上以这种方式进行结构化）： ASP.NET（aspx / ascx） 代码隐藏（C＃） 业务逻辑层（c＃） 数据访问层（c＃） 数据库（Oracle） 主要问题是该代码伪装成面向对象的程序。它实际上违反了两本书中描述的所有准则。 这是业务逻辑层中典型类的示例： public class AddressBO { public TransferObject GetAddress(string addressID) { if (StringUtils.IsNull(addressID)) { throw new ValidationException("Address ID must be entered"); } AddressDAO addressDAO = new AddressDAO(); return addressDAO.GetAddress(addressID); } public TransferObject Insert(TransferObject addressDetails) { if (StringUtils.IsNull(addressDetails.GetString("EVENT_ID")) || StringUtils.IsNull(addressDetails.GetString("LOCALITY")) || …
4
使用数据库时保持面向对象和可测试性
使用数据库但保持单元可测试性的一些OOP策略是什么？假设我有一个User类，并且我的生产环境适用于MySQL。我看到了两种可能的方法，如下所示使用PHP： 通过在与接口$ DATA_SOURCE load()和save()，抽象数据的后端源。测试时，请传递其他数据存储。 $ user =新用户（$ mysql_data_source）; $ user-> load（'bob'）; $ user-> setNickname（'Robby'）; $ user-> save（）; 使用访问数据库并将结果行传递给用户的构造函数的工厂。测试时，手动生成$ row参数，或在UserFactory :: $ data_source中模拟对象。（如何保存对记录的更改？） class UserFactory { static $data_source; public static function fetch( $username ) { $row = self::$data_source->get( [params] ); $user = new User( $row ); return $user; } } 我旁边有设计模式和简洁代码，但我一直在努力寻找适用的概念。
10
在什么时候为了更多的钱而放弃一些软件开发原则？
我想把这个问题扔出去，有趣地看看介质在哪里。 我要承认，在过去的12个月中，我获得了TDD和软件开发中的许多敏捷价值。我对软件开发的进步感到不知所措，以至于我永远都不会放弃它们。直到...我被任命为承包人，这使我当年的实得工资翻了一番。 我加入的公司没有遵循任何特定的方法，团队还没有听说过代码气味，SOLID等问题，而且如果团队从未做到过，我当然也不会浪费时间进行TDD在实践中看到了单元测试。我卖完了吗？不，不是完全...代码将始终被“干净地”编写（按照Bob叔叔的教）），并且SOLID的原理将始终应用于需要的我编写的代码。尽管对我来说测试已经放弃了，但坦率地说，公司无法承担如此未知的任务，即使我确实创建了测试框架，他们也永远不会正确使用/维护测试框架。 以此为例，您会说开发人员出于金钱/个人其他利益而绝不放弃其工艺原则的观点？我了解这可能是一种非常个人的看法，即人们对自己的需求，业务需求以及工艺等方面的关注程度。但是，可以考虑，例如，如果公司决定宁愿进行测试，则可以放弃测试。测试团队，而不是理解编程中的单元测试，那会不会像我那样原谅自己？因此，考虑到您会丢掉一些东西，通常业务中应该有相等的成本来弥补您丢掉的东西-希望如此，除非您当然愿意掏腰包而不是依靠社区/社会合作； ）。 加倍您的钱，回到RAD？或继续前进，寻找正在做敏捷的人，再也不回头...
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.