Questions tagged «integration-tests»

集成测试是软件测试中的阶段，在该阶段中，将各个软件模块组合在一起并作为一个整体进行测试。不需要模拟或存根；一切都经过生产测试。

4
BDD是否可扩展到大中型项目？
在您阅读的有关BDD（行为驱动开发）的每个网站中，您都可以找到一个非常简单的好例子，向您展示定义需求的显而易见和容易。但是，尝试在大型产品（而不是计算器示例）中实施此过程，向我展示了事情可能变得（或将变得）非常复杂且难以理解。特别是在稍后更改请求意味着为此需要进行大量的工作来更正集成测试。 所以我想知道，BDD真的值得吗？它是否解决了其他技术无法解决的问题！
5
如何对需要Web服务调用的类进行单元测试？
我正在尝试测试一个调用某些Hadoop Web服务的类。代码几乎是以下形式： method() { ...use Jersey client to create WebResource... ...make request... ...do something with response... } 例如，有一个创建目录方法，一个创建文件夹方法等。 鉴于代码正在处理我无法控制的外部Web服务，我该如何对其进行单元测试？我可以尝试模拟Web服务客户端/响应，但这违反了我最近看到的指导方针：“不要模拟您不拥有的对象”。我可以设置一个虚拟Web服务实现-仍然构成“单元测试”还是将其作为集成测试？只是不可能在如此低的水平上进行单元测试-TDD从业者将如何做到这一点？
7
当成为团队的新成员时，您如何处理现有集成和单元测试的质量？
我在职业生涯中遇到的一个反复出现的主题是成为新的开发人员加入团队，并很快对现有的单元和集成测试套件产生内在的不信任。 在面试过程中，管理层告诉您，他们“大力支持单元测试”，并公开鼓励他们进行测试。他们可以，但是关于测试本身的一切都是错误的。就像他们声称拥有100％集成测试覆盖率但少于10％可重复单元测试覆盖率时声称100％覆盖率这一事实。我发现了一些其他问题： 在什么是单元测试和什么是集成测试之间没有明确的指示。单元测试和集成测试在同一个类别中混合在一起。 尚未声明对特定环境的数据库中非常特定的动态数据有明确依赖关系的集成测试。 非事务集成测试，基本上是可能会或可能不会麻烦自行清理的测试，有时需要手动数据库“清理”以使测试可重复。 绝不进行任何模拟，而应用程序代码则需要进行大修，以使模拟成为可能。换句话说，设计时不要考虑测试。 没有明确的命名约定可以快速查看测试名称并大致确定要进行的测试。 这并不是说所有测试都是无用的或不好的，很多测试都相当好并且值得保留，但是有时候感觉就像淘金。我故意避免运行测试，只是因为我担心为黑箱测试用例搞砸数据库。 从本质上讲，这使我对单元和集成测试产生了固有的不信任感，而我个人没有以某种方式编写或审查这些测试。在某种程度上，如果您对测试套件的质量不抱有信心，那么它实际上对团队或项目毫无价值。 当您发现自己处于这种情况时该怎么办？您认为最佳的攻击计划是应对此类问题？ 是否应该在跨发行版的巨大努力下重构所有测试？您是否应该放弃这个旧项目可能会有一天可靠的单元测试范围的想法？
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之上的薄层。为了测试任何实体（它们都直接使用其功能），我必须将其变成一个接口和一个类，并将其注入所有实体中。那只是一个例子。 因此，在回答这个问题时，请记住，我必须在编写测试方面投入大量资金。
4
整理数据太麻烦时如何测试？
我正在编写一个解析器，作为其中的一部分，我有一个Expander将单个复杂语句“扩展”为多个简单语句的类。例如，它将扩展此内容： x = 2 + 3 * a 变成： tmp1 = 3 * a x = 2 + tmp1 现在，我正在考虑如何测试此类，特别是如何安排测试。我可以手动创建输入语法树： var input = new AssignStatement( new Variable("x"), new BinaryExpression( new Constant(2), BinaryOperator.Plus, new BinaryExpression(new Constant(3), BinaryOperator.Multiply, new Variable("a")))); 或者我可以将其编写为字符串并进行解析： var input = new Parser().ParseStatement("x = 2 + 3 * a"); …
1
如何测试文件阅读器？
我正在一个具有几种文件格式的项目。某些格式由.xsds指定，其他格式由各自网站上的文档指定，而某些格式是自定义的内部格式，没有文档。姆哈哈哈哈哈 有什么问题？ 我想测试我的文件阅读器，但是我不确定如何去做。应用程序的流程是这样的： file.___ ===> read by FileReader.java ===> which creates a Model object FileReader接口在哪里 public interface FileReader { public Model read(String filename); } 在Model拥有一批在读文件已填充属性。看起来像 public class Model { List<String> as; List<String> bs; boolean isAPain = true; // ... } 我尝试了什么？ 我唯一的想法是为每种文件格式创建文件“生成器”。这些生成器基本上是生成器，它们接受一些变量（例如，要在文件中生成的注释数量），并输出一个样本文件，然后我将其读入并将结果Model与我最初用于生成文件的变量进行比较。 但是，这有一些问题： 它生成的文件看起来不像真实文件。生成器绝不了解上下文。 由于我是手动设置变量的生成器，因此很难识别生成器是否针对边缘情况生成了。这种方法仅比我创建十几个示例文件更好。 有没有更好的方法可以做到这一点？ 编辑：将单元更改为集成，因为这实际上是我的意思。 EDIT2：这是我提到的边缘案例的示例。 每个文件代表一个由顶点和边组成的图形。这些顶点和边可以以不同的方式连接，因此： v1 …
6
为什么需要单元测试来测试存储库方法？
我需要在这个问题上扮演一个恶魔倡导者，因为由于缺乏经验我无法很好地捍卫它。这是交易，我从概念上得到了单元测试和集成测试之间的区别。当专门关注持久性方法和存储库时，单元测试可能会通过Moq之类的框架使用模拟，以断言所搜索的订单已按预期返回。 假设我已经建立了以下单元测试： [TestMethod] public void GetOrderByIDTest() { //Uses Moq for dependency for getting order to make sure //ID I set up in 'Arrange' is same one returned to test in 'Assertion' } 因此，如果我设置好OrderIdExpected = 5并且我的模拟对象返回5了ID，那么我的测试就会通过。我知道了。我对代码进行了单元测试，以确保我的代码瓶坯返回期望的对象和ID，而不返回其他内容。 我将得到的参数是这样的： “为什么不跳过单元测试并进行集成测试呢？这是一起测试数据库存储过程和代码的重要性。当最终我想知道数据库是否调用时，进行单元测试和集成测试似乎是多余的工作。我知道测试需要花费更长的时间，但是无论如何都必须运行和测试它们，所以对我来说，两者都显得毫无意义。只需对重要问题进行测试。” 我可以用诸如以下的教科书定义来捍卫它：“嗯，这是一个集成测试，我们需要将代码作为单元测试和yada，yada，yada分别进行测试。”这种情况是一种纯粹的实践解释与现实的对比正在消失。有时我会碰到这种情况，如果我无法捍卫最终依赖于外部依赖关系的单元测试代码背后的原因，那我就没有理由了。 非常感谢您对这个问题的任何帮助，谢谢！
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, …
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年前关闭。 您知道哪种软件测试？我听说过测试驱动开发，单元测试等，但是不了解它们的重要性和差异。例如，为什么我们要使用回归测试或验收测试。他们提供什么优势？
2
我如何知道我是否有足够的单元测试范围来删除集成测试？
我正在使用旧系统（这意味着它是在没有测试的情况下编写的）。我们试图通过编写集成测试来测试某些系统，这些集成测试从外部测试功能。 这使我有信心重构代码的某些部分，而不必担心会破坏它。但是问题在于这些集成测试需要一个部署（2分钟以上）和很多分钟才能运行。而且，它们很难维持。它们每个都覆盖了数千行代码，当其中一个中断时，可能需要花费数小时来调试原因。 我最近为这些功能更改编写了很多单元测试，但是在提交之前，我总是做一个新的部署并运行所有集成测试，以确保我不会错过任何东西。至此，我知道我的单元测试和某些集成测试与它们的测试重叠。 我怎么知道我的良好单元测试足以覆盖不良的集成测试，以便我可以删除该集成测试？
5
如何创建可扩展且无副作用的集成测试？
在当前的项目中，我很难找到一个好的解决方案来创建没有副作用的可扩展集成测试。关于副作用自由属性的一些澄清：它主要是关于数据库的；测试完成后，数据库中不应有任何更改（应保留状态）。也许可伸缩性和状态保存并没有融合在一起，但是我真的想推动一个更好的解决方案。 这是一个典型的集成测试（这些测试涉及数据库层）： public class OrderTests { List<Order> ordersToDelete = new ArrayList<Order>(); public testOrderCreation() { Order order = new Order(); assertTrue(order.save()); orderToDelete.add(order); } public testOrderComparison() { Order order = new Order(); Order order2 = new Order(); assertFalse(order.isEqual(order2); orderToDelete.add(order); orderToDelete.add(order2); } // More tests public teardown() { for(Order order : ordersToDelete) order.delete(); …
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.