blocks|key|1537183|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|entityMap^0^^$0|@$1|2|3|-4|4|5|6|B|7|@]|8|@]|9|$]]]|A|$]]

<p>It depends, but testing with production databases is typically a bad idea.</p>
<h2>Tests are for building confidence in your software</h2>
<p>The point of QA practices such as conducting tests is to build confidence that the system delivers the value it is supposed to deliver. For example, a bank might want to ensure that transactions are reflected correctly in the account balances.</p>
<p>The problem here is that we are running the tests because we <em>don't yet</em> have confidence that it works correctly. Within reason, we have to assume that the system has bugs that our tests might discover. So, we must contain the “blast radius” of a failed test – it should not be possible for a test to impact production workloads. For example, the bank might set up a test environment in order to verify the transaction management logic. If a bug ends up deleting all accounts in the test environment, that's a fixable problem and not a “resume-generating event”.</p>
<p>Eventually, there will be enough confidence to deploy the system in the production environment. If you already have enough confidence, then sure, running some final tests in production is fine.</p>
<h2>Safeguarding against problems when testing in production</h2>
<p>With automated tests, there is a “what tests the tests?” problem. Automated tests are software too, and might contain bugs. If you rely on features like database transactions to isolate test workloads, there's always a chance that your code doesn't use these isolation features correctly and accidentally leaks changes into the production environment. So if you have to test in production for whatever reason, it would make sense to think about strategies to verify that your testing methods work as expected. Some other isolation methods might be more difficult to use incorrectly, for example if the database can provide a test access without any write permissions.</p>
<p>Sometimes, testing with production systems is inevitable. For example, you might be integrating with external systems that cannot provide a test environment, or setting up a testing environment with sufficient fidelity might be prohibitively expensive (i.e. more expensive than dealing with the fallout of a test gone wrong in production). It is still possible to manage risks here, in particular by testing other parts of the system first, and by also using other QA techniques than just tests, for example more thorough code reviews on those areas that can only be tested in production.</p>
<p>There are some strategies that can help build confidence when running on production systems, following the general idea that we want to minimize the impact of errors caused in production.</p>
<ul>
<li>Most importantly, there should be a solid and tested backup strategy that makes it possible to quickly recover. There might also be application-level features to fix mistakes, for example event logs and admin dashboards. But good backup and disaster recovery practices typically mean that it would also be straightforward to set up a test environment with the same data.</li>
<li>Event-driven architectures that can always recompute the current state from an append-only event stream have an advantage here. They also make it easier to test new functionality with read-only access to data.</li>
<li>New changes for which you have little confidence shouldn't be applied in one go, but should likely use a gradual rollout – if there are problems, they will only affect a fraction of your system. For example, the bank might initially roll out a new feature to 100 customers, and then wait for a while for possible errors to appear. A live system might also have a number of dummy accounts for testing or demo purposes, but handled carelessly they could also cause problems.</li>
</ul>
<h2>Balancing costs and risks</h2>
<p>So how to arrive at a decision on testing in production vs setting up a separate test environment? There are a number of costs, benefits, risks, and mitigations that have to be balanced against each other.</p>
<ul>
<li><p>For testing in production, we have to consider the benefits of the high-fidelity tests made possible in production, but also the costs and risks of causing problems in production, and the costs of implementing additional mitigations and safeguards.</p>
</li>
<li><p>For testing in a dedicated test environment, we have the cost of setting up a test environment with sufficient fidelity.</p>
</li>
</ul>
<p>Simply because there are fewer risks involved, setting up a dedicated test environment typically has lower expected costs. For example, testing in a production system might have small but non-zero chance of causing a business-critical (or even life-threatening) problems. It is difficult to account well for low-probability but high-impact risks. As an approximation, we can summarize that testing in production is appropriate when the following relation holds:</p>
<blockquote>
<p>cost of setting up a separate test environment<br />
&gt;<br />
cost × risk of causing problems in production<br />
+ cost of mitigations and safeguards for production testing</p>
</blockquote>
<p>It is worth recalling a point made above: as the system progresses through a QA process, our confidence in the system increases and the risks of using that system decrease. Thus, some degree of testing in production is probably appropriate very late in a QA process.</p>
<p>It may also be worth considering that as an organization and its software development processes mature, risks and costs shift.
For a hobby project or a startup in stealth mode, production problems have fairly low impact, making tests in production less scary.
Most companies do have customers and business-critical processes though, so that the risks make testing in production less affordable.
But as an organization gains confidence to contain problems in production and to recover easily from such problems, some degree of “shift-right” QA becomes attractive.</p>


<p>I'm writing integration tests for an already existing product.
I'm using the <a href="https://docs.spring.io/spring-framework/docs/current/reference/html/testing.html#integration-testing" rel="nofollow noreferrer">Spring Integration Testing suite</a> for this purpose, which allows testing a real DB connection by creating a transaction and rolling it back after the test execution.</p>
<p>This looks safe to be used to test also against a production database, however I searched far and wide on the web and I didn't find any reference about which environment to use for performing this kind of test.</p>
<p>I thought about what would be the best fit, and I realized that there are good reasons for both production databases and test databases.</p>
<h5>Pro of using a production database:</h5>
<ul>
<li>Any misalignment between the test and the prod DB is revealed</li>
<li>Test on real data</li>
<li>Test on real DB configuration</li>
</ul>
<h5>Pro of using a test database:</h5>
<ul>
<li>Production keys are kept away from the test environment</li>
<li>If the integration test is misconfigured, the production DB won't be corrupted</li>
</ul>
<p>So I found good reasons for both of them, and I didn't decide which DB to use for my case. Also, I didn't find any bibliography even if I've read lots of bibliographies about integration tests.</p>
<p>My question is: is performing integration tests on a production DB a bad practice?</p>


Is performing integration tests on a production DB a bad practice?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

我正在为一个已经存在的产品编写集成测试。为此，我使用了弹簧集成测试套件，它允许通过创建事务并在测试执行后回滚来测试真正的DB连接。这看起来很安全，也可以用生产数据库进行测试，但是我在网上搜索了很多地方，并且没有找到任何关于使用哪个环境来执行这种测试的参考。我想过什么才是最合适的，我意识到生产数据库和测试数据库都有很好的理由。使用生产数据库的Pro：测试与prod DB之间的任何不对齐都会被发现。对

问在生产DB上执行集成测试是一种糟糕的做法吗？
EN

Pro：

Pro：

回答 1

Software Engineering用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在生产DB上执行集成测试是一种糟糕的做法吗？EN

Pro：

Pro：

回答 1

Software Engineering用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在生产DB上执行集成测试是一种糟糕的做法吗？
EN