Questions tagged «tdd»

TDD代表测试驱动开发或测试驱动设计。这是在编写代码以使其满足要求之前编写单元测试的实践,即所谓的“红绿色重构周期”。

4
如何使用单元测试和TDD来测试主要依赖数据库CRUD操作的应用程序?
在工作中,我的项目之一主要是获取从外部客户端传入的数据并将其保存在数据库中。这是一个使用JPA的Java企业应用程序,我们的大多数逻辑都围绕CRUD操作展开。 我们的大多数错误都以一种或另一种方式涉及JPA。 示例1:如果单击保存按钮两次,JPA可能会尝试第二次将同一实体插入数据库,从而导致主键冲突。 示例2:您从数据库中检索一个实体,对其进行编辑,然后尝试更新其数据。JPA可能会尝试创建一个新实例,而不是更新旧实例。 解决方案通常需要添加/删除/更改JPA批注。其他时候,它与修改DAO逻辑有关。 我无法弄清楚如何使用单元测试和TDD对我们的代码充满信心。我不确定这是因为单元测试和TDD不合适,还是我错误地解决了这个问题。 单元测试似乎不合适,因为我只能在运行时发现这些问题,并且需要部署到应用服务器以重现这些问题。通常需要涉及数据库,而我认为这超出了单元测试的定义:这些是集成测试。 TDD似乎不合适,因为部署+测试反馈循环是如此之慢,以至于我效率低下。部署+测试反馈循环需要3分钟以上的时间,这就像我专门针对所编写的代码运行测试一样。要运行所有集成测试,需要30分钟以上的时间。 在此模型之外有代码,我总是尽可能地进行单元测试。但是,我们的大多数错误和最大的时间浪费总是涉及JPA或数据库。 还有另一个类似的问题,但是如果我遵循建议,我将包装代码中最不稳定的部分(JPA)并测试除此以外的所有内容。就我的问题而言,我将处于同样的糟糕境地。打包JPA之后的下一步是什么?海事组织,这个问题(也许)是回答我的问题的步骤,而不是答案。
22 java  unit-testing  tdd  jpa 

2
如何创建将修复测试视为优先事项的环境?
我是一家中型公司的软件工程师。我们在TeamCity上运行着一个相当强大的测试平台。它会在每次签入时进行单元测试,并每天运行单元测试/ BVT。 问题是-我们有很多损坏的单元测试。 通常,如果单元测试经常中断且无法维护,我会提出毫无意义的建议。无法查看更改是否引起了回归,从而消除了单元测试平台的大部分价值。 我想种下一种会养成良好习惯文化的种子-破坏测试时将其修复,将其视为有价值的东西,将测试的固定与其他工作一起放在优先位置。 我已经尝试过贿赂(烘焙食品!),只是简单地询问,并与团队负责人交谈。每个人都说这是一个好主意,但我认为这是唯一对此做任何事情的人。 鼓励他人修复测试并在冲刺中优先考虑修复的最佳方法是什么? 如果有比较主观的方式提出这个问题,我很乐意接受任何提示。

5
测试列表…针对每种情况都在同一测试中还是在一项测试中?
我正在测试某个功能是否可以实现列表中的预期功能。所以我要测试 f(null) -> null f(empty) -> empty f(list with one element) -> list with one element f(list with 2+ elements) -> list with the same number of elements, doing what expected 为此,最好的方法是什么? 在同一(方法)测试中测试所有案例,名称为“ WorksAsExpected” 针对每种情况进行一次测试,因此 “ WorksAsExpectedWhenNull” “ WorksAsExpectedWhenEmpty” “ WorksAsExpectedWhenSingleElement” “ WorksAsExpectedWhenMoreElements” 我没有想到的另一种选择:-)
21 unit-testing  tdd 

5
编写实现后如何纠正测试中的错误
如果正确实施逻辑后,测试仍然失败(因为测试中有错误),则TDD中的最佳措施是什么? 例如,假设您要开发以下功能: int add(int a, int b) { return a + b; } 假设我们按照以下步骤进行开发: 编写测试(尚无功能): // test1 Assert.assertEquals(5, add(2, 3)); 导致编译错误。 编写一个虚拟函数实现: int add(int a, int b) { return 5; } 结果:test1通过。 添加另一个测试用例: // test2 -- notice the wrong expected value (should be 11)! Assert.assertEquals(12, add(5, 6)); 结果:test2失败,test1仍然通过。 编写实际的实现: int …
21 tdd  mistakes 

5
如何对需要Web服务调用的类进行单元测试?
我正在尝试测试一个调用某些Hadoop Web服务的类。代码几乎是以下形式: method() { ...use Jersey client to create WebResource... ...make request... ...do something with response... } 例如,有一个创建目录方法,一个创建文件夹方法等。 鉴于代码正在处理我无法控制的外部Web服务,我该如何对其进行单元测试?我可以尝试模拟Web服务客户端/响应,但这违反了我最近看到的指导方针:“不要模拟您不拥有的对象”。我可以设置一个虚拟Web服务实现-仍然构成“单元测试”还是将其作为集成测试?只是不可能在如此低的水平上进行单元测试-TDD从业者将如何做到这一点?

6
添加单元测试对知名的旧版代码有意义吗?
我说的是TDD意义上的单元测试。(不是自动的“集成”,或者您喜欢称之为测试的东西。) 遗留代码,如:(C ++)没有测试的代码。(请参阅:Michael Feathers的“ 旧版代码有效工作”) 但是还有一些遗留代码,例如:我们的团队在过去10到5年中一直在使用的代码,因此我们通常对将事物放置在何处可以改变事物有一个很好的认识。 我们确实对某些模块进行了单元测试(通过Boost.Test),这些模块后来出现或很自然地适合单元测试(常见的应用程序特定容器,字符串填充,网络助手等)。 我们尚未进行适当的自动化验收测试。 现在,最近,我很高兴地实现了3个新的面向用户的功能。 每个人花了我大约1-2个小时来快速掌握我需要更改的代码部分,花了1-2小时来实现我需要更改的(小)代码,另外花了1-2个小时来确保应用程序之后正确运行,并且确实应该这样做。 现在,我确实添加了很少的代码。(我认为每个功能都有一个方法和一些调用行。) 分解出这段代码(通过WEwLC中建议的任何一种方法),以使单元测试变得有意义(而不是完整的重言式)将很容易又花费2-4个小时,甚至更多。这将为每个功能增加50%-100%的时间,而没有立即的好处,因为 我不需要单元测试即可了解有关代码的任何信息 手动测试的工作量是相同的,因为我仍然需要测试代码是否正确集成到应用程序的其余部分中。 当然,如果,以后,“有人”走过来,碰到的代码,他理论上可以有从单元测试的一些好处。(仅从理论上讲,因为经过测试的代码孤岛将生活在未经测试的代码海洋中。) 因此,“这一次”,我选择不做添加单元测试的艰苦工作:对代码进行更改以使要测试的东西要比对代码进行更改(要正确(清晰地)实现功能)复杂得多。 这是强耦合旧代码的典型代表吗?我是不是很懒?我们是否将团队的优先顺序设置错了?还是我谨慎,只测试开销不太高的东西?
21 c++  tdd  legacy  unit-testing 

6
使用TDD时如何删除功能或功能
在有关TDD的文章中,我经常在重构步骤中读到“删除重复项”或“提高可读性”。但是,什么使我删除了未使用的功能? 例如,假设有一个C带有方法a()和的类b()。现在我认为有一个f()被驱动的方法会很不错C。实际上,除定义/描述的单元测试外,f()所有对的调用都将替换。不再需要-测试除外。b()b() 删除b()和使用它的所有测试是否保存?那是“提高可读性”的一部分吗?

3
为有状态系统设计单元测试
背景 在我完成学业后,测试驱动开发得到了普及。我正在尝试学习它,但是一些主要的事情仍然无法解决。TDD的支持者说了很多类似的东西(以下称为“单一声明原则”或SAP): 一段时间以来,我一直在思考TDD测试如何尽可能简单,富有表现力和优雅。本文探讨了使测试尽可能简单和可分解的感觉:针对每个测试中的单个断言。 来源:http://www.artima.com/weblogs/viewpost.jsp? thread = 35578 他们还说这样的话(以下称为“私有方法原理”或PMP): 通常,您不直接对私有方法进行单元测试。由于它们是私有的,因此请考虑将其作为实现细节。没有人会打电话给他们中的一个,并期望它以特定的方式工作。 相反,您应该测试您的公共接口。如果调用您的私有方法的方法按预期工作,则可以假定您的私有方法正常工作。 资料来源:您如何对私有方法进行单元测试? 情况 我正在尝试测试有状态的数据处理系统。给定接收数据之前的状态,系统可以对完全相同的数据执行不同的操作。考虑一个简单的测试,该测试建立系统中的状态,然后测试给定方法要测试的行为。 SAP建议我不要测试“状态构建过程”,我应该假设状态是我希望从构建代码中得到的状态,然后测试我要测试的一个状态更改 PMP建议我不能跳过此“状态建立”步骤,而只能测试独立控制该功能的方法。 我实际代码中的结果是测试膨胀,复杂,冗长且难以编写。而且,如果状态转换发生变化,则必须更改测试……这对于小型,高效的测试是可以的,但对于这些冗长的测试却非常耗时且令人困惑。通常如何做?

3
TDD和重构遇到的困难(或者-为什么这比应该的要痛苦得多?)
我想教自己使用TDD方法,而我有一个项目想要工作一段时间。这不是一个大项目,所以我认为这将是TDD的不错的选择。但是,我感觉有些不对劲。让我举个例子: 在较高级别上,我的项目是Microsoft OneNote的加载项,它使我可以更轻松地跟踪和管理项目。现在,如果我决定建立自己的自定义存储和后端的一天,我还希望保持与OneNote分离的业务逻辑。 首先,我从一个基本的普通单词接受测试开始,概述了我希望我的第一个功能要做的事情。看起来像这样(为简洁起见,将其复制): 用户点击创建项目 用户输入项目标题 验证项目创建正确 跳过UI内容和一些中介计划,我来进行第一次单元测试: [TestMethod] public void CreateProject_BasicParameters_ProjectIsValid() { var testController = new Controller(); Project newProject = testController(A.Dummy<String>()); Assert.IsNotNull(newProject); } 到目前为止,一切都很好。红色,绿色,重构等。现在它实际上需要保存内容。在这里减少一些步骤,我对此很满意。 [TestMethod] public void CreateProject_BasicParameters_ProjectMatchesExpected() { var fakeDataStore = A.Fake<IDataStore>(); var testController = new Controller(fakeDataStore); String expectedTitle = fixture.Create<String>("Title"); Project newProject = testController(expectedTitle); Assert.AreEqual(expectedTitle, newProject.Title); } …

3
单元测试C ++:要测试什么?
TL; DR 编写好的,有用的测试很困难,并且在C ++中代价很高。您是否有经验的开发人员可以就什么以及何时进行测试分享您的理论依据? 很长的故事 我曾经做过测试驱动的开发,实际上是整个团队,但对我们来说效果不佳。我们有很多测试,但是它们似乎从来没有覆盖我们有实际错误和回归的情况-通常是在单元交互时发生的,而不是因为它们孤立的行为而发生。 这通常很难在单元级别进行测试,以至于我们停止了TDD测试(组件确实可以加快开发速度),而花了更多时间增加集成测试的覆盖范围。尽管小型单元测试从未捕获任何实际的错误,并且基本上只是维护开销,但集成测试确实值得付出努力。 现在,我继承了一个新项目,并且想知道如何进行测试。它是本机C ++ / OpenGL应用程序,因此集成测试并不是真正的选择。但是C ++中的单元测试比Java中的要难一些(您必须显式地制作东西virtual),并且该程序不是很面向对象的,所以我无法模拟/存根一些东西。 我不想为了编写测试而仅仅为了编写一些测试而拆开并OO化整个过程。所以我问你:我应该为测试写什么?例如: 我希望经常更改的函数/类? 难以手动测试的函数/类? 已经易于测试的功能/类? 我开始研究一些受人尊敬的C ++代码库,以了解它们如何进行测试。现在,我正在研究Chromium源代码,但发现很难从代码中提取其测试依据。如果有人有一个很好的例子或关于C ++用户(委员会,书籍作者,Google,Facebook,Microsoft等人的看法)如何发表文章的帖子,那将特别有帮助。 更新资料 自编写此书以来,我一直在这个网站和网络上进行搜索。找到了一些好东西: 什么时候不进行单元测试? /programming/109432/what-not-to-test-when-it-comes-to-unit-testing http://junit.sourceforge.net/doc/faq/faq.htm#best 可悲的是,所有这些都是以Java / C#为中心的。用Java / C#编写大量测试不是一个大问题,因此收益通常超过了成本。 但是正如我上面所写,在C ++中要困难得多。尤其是如果您的代码库不是那么OO,那么您就必须认真弄乱事情,以获得良好的单元测试覆盖率。例如:我继承的应用程序具有一个Graphics名称空间,该名称空间是OpenGL之上的薄层。为了测试任何实体(它们都直接使用其功能),我必须将其变成一个接口和一个类,并将其注入所有实体中。那只是一个例子。 因此,在回答这个问题时,请记住,我必须在编写测试方面投入大量资金。

5
如何在测试抗文化中开始测试?[关闭]
已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗?更新问题,使其仅通过编辑此帖子来关注一个问题。 4年前关闭。 我要坦白:正式的自动化测试从来都不是我编程背景的一部分。我现在在一家非常大的公司工作,有很多开发人员(其中大多数是某种类型的Web开发人员),很明显,他们中的大多数人都没有测试*。(*我不会继续正式发言;请推断出来。) 如果我等待组织的支持开始测试,那将永远不会发生。如果我试图通过推动管理层的测试来“从内部改变事情”,那么在改变发生之前,我将精疲力尽。我需要立即开始测试。 但是对于TDD及其同类产品,我将最终获得大量测试代码以及​​生产代码。我们的版本控制系统(全部为集中式)并不是为了存储测试代码而组织的。我必须在我的工作站上找到所有放置的地方。 是否有可能在一种不重视或不提供工具的文化中开始个人软件测试实践?当官方工具和组织没有测试,框架和自动化的地方时,您使用什么技术和工具来进行测试?
20 testing  tdd 

5
单元测试是否会导致过早的泛化(特别是在C ++中)?
初步说明 我不会区分不同种类的测试,在这些站点上已经有一些与此有关的问题。 我会采取什么样的存在,并且说:单位的“测试应用程序的最小单位可分离”的意义测试从这个问题实际上导出 隔离问题 程序的最小可隔离单元是什么。好吧,正如我所见,它(高度?)取决于您所使用的语言。 Micheal Feathers谈到接缝的概念:[WEwLC,p31] 接缝是一个您可以更改程序行为而无需在该位置进行编辑的位置。 而且,在不进行细节讨论的情况下,我了解到在单元测试的上下文中存在的缝隙—在程序中可以使“测试”与“单元”进行交互。 例子 单元测试-尤其是C ++中的单元测试-要求被测试的代码添加更多的接缝,这对于给定的问题是严格要求的。 例: 在非虚拟实现就足够的地方添加虚拟接口 拆分-generalizing(?)-一个(较小的)类,进一步“恰好”以方便添加测试。 将单个可执行项目拆分为看似“独立”的库,“公正”以便于为测试而独立地编译它们。 问题 我将尝试一些可能会问相同问题的版本: 单元测试是“仅”对应用程序代码进行结构化的一种方式,这对单元测试是有益的,还是实际上对应用程序结构有利。 是需要的代码泛化作出任何它的单位可测试非常有用,但单元测试? 添加单元测试是否会强制一个泛化? 从问题域的角度来看,形状单元测试对代码的“总是”作用力是否也对代码总体而言是一种良好的形状? 我记得有一条经验法则,直到您需要/直到有第二个地方使用该代码时,它才会泛化。使用单元测试,总是有第二个地方使用代码-即单元测试。那么,这个理由足以概括吗?

2
嵌入式C开发人员的良好单元测试示例
关闭。这个问题是题外话。它当前不接受答案。 想改善这个问题吗? 更新问题,使它成为软件工程堆栈交换的主题。 6年前关闭。 下周,我将与我的部门进行有关单元测试和测试驱动开发的演讲。作为其中的一部分,我将展示一些我最近编写的代码中的真实示例,但我也想展示一些我将在演讲中编写的非常简单的示例。 我一直在网上寻找良好的例子,但一直在努力寻找任何特别适合我们开发领域的例子。我们编写的几乎所有软件都是在小型微控制器上运行的深层控制系统。只要您远离“底层”层,就有很多C代码很容易适用于单元测试(我将在PC上而不是在目标本身上谈论单元测试):直接对话的东西到微控制器外设。但是,我发现的大多数示例都倾向于基于字符串处理(例如出色的Dive Into Python罗马数字示例),并且由于我们几乎从未使用过字符串,因此这实际上并不适合(关于我们的代码通常使用的唯一库函数)是memcpy,memcmp和memset,strcat 或正则表达式不太正确)。 那么,问题就来了:请问有人可以提供一些很好的功能示例,这些功能可以用来在实时会话中演示单元测试吗?在我的观点(可能会发生变化)中,一个好的答案可能是: 一个足够简单的功能,任何人(甚至只是偶尔写代码的人)都可以理解; 看起来没有意义的函数(即计算奇偶校验或CRC可能比将两个数字相乘并添加随机常数的函数更好); 一个足够短的函数,可以在一个人的房间里书写(我可能会利用Vim的许多剪贴板来减少错误……); 该函数以数字,数组,指针或结构为参数,并返回相似的内容,而不是处理字符串。 具有简单错误(例如>而不是>=)的函数易于插入,在大多数情况下仍然可以使用,但在某些特殊情况下会中断:易于通过单元测试进行识别和修复。 有什么想法吗? 尽管可能无关紧要,但是测试本身可能会使用Google Test Framework以C ++编写:我们所有的标头都已经包含了#ifdef __cplusplus extern "C" {包装器;到目前为止,这与我已经完成的测试效果很好。

8
一个单元的单个或多个文件用于单元测试?
在研究单元测试最佳实践以帮助为我的组织制定准则时,我遇到了一个问题,即分离测试装置(测试类)还是将一个类的所有测试保存在一个文件中是更好还是有用。 首先,我纯粹是指“单元测试”,它们是针对单个类,每个测试一个断言,所有依赖项都被嘲笑的白盒测试。 一个示例场景是一个类(称为Document),它具有两个方法:CheckIn和CheckOut。每种方法实现控制其行为的各种规则等。按照每次测试一个断言的规则,每种方法我将有多个测试。我可以将所有测试放在一个单独的DocumentTests类中,其名称类似于CheckInShouldThrowExceptionWhenUserIsUnauthorized和CheckOutShouldThrowExceptionWhenUserIsUnauthorized。 或者,我可以有两个单独的测试类:CheckInShould和CheckOutShould。在这种情况下,我的测试名称将被缩短,但是它们会被组织起来,以便针对特定行为(方法)的所有测试都在一起。 我确定这两种方法都有优缺点,并且想知道是否有人使用多个文件进行了路由,如果是,为什么?或者,如果您选择了单文件方法,为什么感觉更好呢?

4
在不这样做的公司中实施单元测试
我公司的软件开发负责人只是“辞职”(即被解雇),我们现在正在研究改善公司的开发实践。我们希望在以后创建的所有软件中实施单元测试。 开发人员的反馈是: 我们知道测试很有价值 但是,您总是在更改规格,因此会浪费时间 而且,您的截止日期太紧了,我们还是没有足够的时间进行测试 CEO的反馈是: 我希望我们的公司进行自动化测试,但我不知道如何实现 我们没有时间编写大型规范文档 开发人员现在如何获得规格?口耳相传或PowerPoint幻灯片。显然,这是一个大问题。我的建议是这样的: 我们还为开发人员提供一组测试数据和单元测试 那是规格。管理层需要清楚,定量地了解其需求。 开发人员可以将其认为需要的任何其他功能放入测试中,而无需测试 好吧,如果您曾经在一家处于这种情况的公司任职,那么您是如何解决问题的?这种方法看起来合理吗?
19 unit-testing  tdd 

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.