中学网站建设工作实施方案,六安市建设网站市场信息价,哈尔滨中企动力公司怎么样,东莞房价2022最新房价去年冬天#xff0c;我为仍在工作的客户编写并发布了一项服务。 总体而言#xff0c;该服务满足了业务需求和性能要求#xff0c;但是使用该服务的一个团队告诉我#xff0c;他们定期遇到一个问题#xff0c;该问题是该服务将返回500个错误#xff0c;并且在重新启动该服… 去年冬天我为仍在工作的客户编写并发布了一项服务。 总体而言该服务满足了业务需求和性能要求但是使用该服务的一个团队告诉我他们定期遇到一个问题该问题是该服务将返回500个错误并且在重新启动该服务之前不会恢复正常。 我问这是什么时候发生的 戴上了侦探的帽子。 在此博客中我将介绍诊断错误并确定正确的集成测试解决方案以正确方式进行修复的过程。 为此我必须创建一个测试以准确再现服务在PROD中遇到的情况。 我必须创建一个修复程序使测试从失败到通过。 最后我努力提高对所有未来发行版代码正确性的信心这只有通过自动测试才能实现。 诊断错误 在500个错误开始发生时我会仔细阅读服务的日志文件。 他们很快发现了一个非常严重的问题在星期六的午夜之前我的服务将开始引发错误。 最初所有SQLException都发生了各种各样的错误但最终根本原因是相同的 org.springframework.jdbc.CannotGetJdbcConnectionException: Could not get JDBC Connection; nested exception is java.sql.SQLRecoverableException: IO Error: The Network Adapter could not establish the connectionat org.springframework.jdbc.datasource.DataSourceUtils.getConnection(DataSourceUtils.java:80) 此过程持续了几个小时直到次日凌晨重新启动服务服务恢复正常为止。 与检查 洞穴巨魔 DBA我发现要连接的数据库已关闭以进行维护。 确切的细节使我无所适从但我认为这是数据库关闭的大约30分钟的窗口。 因此很明显一旦数据库从中断中恢复我的服务就无法重新连接到数据库。 修复此错误和我过去经常去过的错误的最直接方法是使用Google“从数据库中断中恢复”这很可能导致我遇到一个Stack Overflow线程该线程可以回答我的问题。 然后我将在提供的答案中“复制并粘贴”并推送要测试的代码。 如果生产受到错误的严重影响则在短期内可能需要使用此方法。 就是说应该在不久的将来留出时间来用自动测试来覆盖更改。 因此通常情况下“正确的方式”做事通常意味着大量的字体加载时间投资这句话在这里肯定是正确的。 但是投资回报是花费在修复错误上的时间减少了对代码正确性的信心增加了此外测试可以作为文档在给定场景下的行为的重要形式。 尽管这个特定的测试用例有些深奥但在设计和编写测试无论是单元测试还是集成测试时要牢记这一重要因素给测试起好名字确保测试代码可读性等等。 解决方案1模拟一切 我为该问题编写测试的第一个步骤是尝试“模拟一切”。 尽管Mockito和其他模拟框架非常强大并且变得越来越容易使用但在考虑了此解决方案之后我很快得出结论就是我永远不会有信心除了模拟之外我不会进行任何测试已经写了。 获得“绿色”结果并不会增加我对代码正确性的信心而这首先是编写自动化测试的全部要点 转到另一种方法。 解决方案2使用内存数据库 我编写测试的下一个尝试是使用内存数据库。 我是H2的忠实拥护者过去我广泛使用H2希望它可以再次满足我的需求。 我在这里的时间可能比我应该花费的时间多。 虽然最终这种方法没有成功但花费的时间并没有完全浪费我确实学到了更多有关H2的知识。 以“正确的方式”做事的好处之一尽管此刻通常很痛苦是您可以学到很多东西。 所获得的知识在当时可能没有用但以后可能会有价值。 使用内存数据库的优势 就像我说的那样我在这里的时间可能比我应该花的时间更多但是我确实有希望这种解决方案起作用的原因。 H2和其他内存数据库具有两个非常理想的特征 速度 H2的启动和停止相当快不到一秒。 因此尽管比使用模拟慢一些但我的测试仍会很快。 可移植性 H2可以完全从导入的jar运行因此其他开发人员可以仅提取我的代码并运行所有测试而无需执行任何其他步骤。 另外我最终的解决方案有两个非常重要的缺点下面将作为解决方案的一部分进行介绍。 编写测试 有点有意义但是到目前为止我还没有编写任何一行生产代码。 TDD的主要原则是先编写测试然后编写生产代码。 这种方法论以及确保高水平的测试覆盖率还鼓励开发人员仅进行必要的更改。 这回到了提高对代码正确性的信心这一目标。 以下是我用来测试PROD问题的初始测试用例 RunWith(SpringRunner.class)
SpringBootTest(classes DataSourceConfig.class, properties {datasource.driverorg.h2.Driver,
datasource.urljdbc:h2:mem:;MODEORACLE, datasource.usertest, datasource.passwordtest })
public class ITDatabaseFailureAndRecovery {Autowiredprivate DataSource dataSource;Testpublic void test() throws SQLException {Connection conn DataSourceUtils.getConnection(dataSource);conn.createStatement().executeQuery(SELECT 1 FROM dual);ResultSet rs conn.createStatement().executeQuery(SELECT 1 FROM dual);assertTrue(rs.next());assertEquals(1, rs.getLong(1));conn.createStatement().execute(SHUTDOWN);DataSourceUtils.releaseConnection(conn, dataSource);conn DataSourceUtils.getConnection(dataSource);rs conn.createStatement().executeQuery(SELECT 1 FROM dual);assertTrue(rs.next());assertEquals(1, rs.getLong(1));}
} 最初我觉得使用此解决方案的方向正确。 有一个问题是如何启动H2服务器备份一次有一个问题但是当我运行测试时它失败了并给出了与我的服务在PROD中所经历的类似的错误 org.h2.jdbc.JdbcSQLException: Database is already closed (to disable automatic closing at VM shutdown, add ;DB_CLOSE_ON_EXITFALSE to the db URL) [90121-192] 但是如果我修改测试用例并仅尝试第二次连接数据库 conn DataSourceUtils.getConnection(dataSource); 异常消失了我的测试通过了而无需更改生产代码。 这里不对劲… 为什么此解决方案不起作用 因此使用H2将不起作用。 实际上我花了很多时间尝试使H2正常工作而不是上面建议的时间。 包括故障排除尝试 连接到基于文件的H2服务器实例而不只是一个内存中的远程H2服务器 我什至偶然发现了H2 Server类 该类本来可以解决早先的服务器关闭/启动问题。 这些尝试显然都没有效果。 H2的基本问题至少对于此测试用例而言是尝试连接到数据库如果当前未运行将导致该数据库启动。 正如我的初始测试用例所示这有点延迟但是显然这构成了一个基本问题。 在PROD中当我的服务尝试连接到数据库时它不会导致数据库启动无论我尝试连接多少次。 我的服务日志肯定可以证明这一事实。 接下来是另一种方法。 解决方案3连接到本地数据库 模拟一切都行不通。 使用内存数据库也不会成功。 看来我能够正确重现我的服务在PROD中遇到的方案的唯一方法是连接到更正式的数据库实现。 关闭共享开发数据库是不可能的因此该数据库实现需要在本地运行。 该解决方案的问题 因此在此之前的所有内容都应该很好地表明我确实希望避免走这条路。 我的沉默有一些很好的理由 降低的可移植性如果其他开发人员想要运行此测试则需要在本地计算机上下载并安装数据库。 她还需要确保她的配置详细信息符合测试的期望。 这是一项耗时的任务并且至少会导致一定数量的“带外”知识。 速度较慢总体而言我的测试仍然不太慢但是启动关闭和重新启动即使是针对本地数据库也需要花费几秒钟的时间。 虽然几秒钟听起来不算多但可以通过足够的测试来累加时间。 这是一个主要的问题因为允许集成测试花费更长的时间以后要花更多的时间但是集成测试越快运行它们的频率就越高。 组织争执要在构建服务器上运行此测试意味着我现在需要与已经负担过重的DevOps团队合作在构建框中设置数据库。 即使操作团队没有负担过重我也想尽可能避免这种情况因为这只是又一步。 许可在我的代码示例中我使用MySQL作为测试数据库实现。 但是对于我的客户我正在连接到Oracle数据库。 Oracle确实免费提供了Oracle Express EditionXE但确实有规定。 这些规定之一是不能同时运行两个Oracle XE实例。 除了Oracle XE的特殊情况外在连接到特定产品时许可可能成为一个问题这一点要牢记。 …最后 最初这篇文章要长很多这也给所有 鲜血汗水和眼泪 到现在为止的工作。 最终这些信息对读者而言并不是特别有用即使这是作者写信的方式。 因此事不宜迟一个测试可以准确地重现我的服务在PROD中遇到的情况 Test
public void testServiceRecoveryFromDatabaseOutage() throws SQLException, InterruptedException, IOException {Connection conn null;conn DataSourceUtils.getConnection(datasource);assertTrue(conn.createStatement().execute(SELECT 1));DataSourceUtils.releaseConnection(conn, datasource);LOGGER.debug(STOPPING DB);Runtime.getRuntime().exec(/usr/local/mysql/support-files/mysql.server stop).waitFor();LOGGER.debug(DB STOPPED);try {conn DataSourceUtils.getConnection(datasource);conn.createStatement().execute(SELECT 1);fail(Database is down at this point, call should fail);} catch (Exception e) {LOGGER.debug(EXPECTED CONNECTION FAILURE);}LOGGER.debug(STARTING DB);Runtime.getRuntime().exec(/usr/local/mysql/support-files/mysql.server start).waitFor();LOGGER.debug(DB STARTED);conn DataSourceUtils.getConnection(datasource);assertTrue(conn.createStatement().execute(SELECT 1));DataSourceUtils.releaseConnection(conn, datasource);
} 完整代码在这里 https : //github.com/wkorando/integration-test-example/blob/master/src/test/java/com/integration/test/example/ITDatabaseFailureAndRecovery.java 修复 所以我有我的测试用例。 现在是时候编写生产代码以使我的测试显示为绿色。 最终我从一个朋友那里得到了答案但是可能会在使用足够的谷歌搜索功能时偶然发现了这个答案。 最初我在服务配置中设置的数据源实际上看起来像这样 Bean
public DataSource dataSource() {org.apache.tomcat.jdbc.pool.DataSource dataSource new org.apache.tomcat.jdbc.pool.DataSource();dataSource.setDriverClassName(env.getRequiredProperty(datasource.driver));dataSource.setUrl(env.getRequiredProperty(datasource.url));dataSource.setUsername(env.getRequiredProperty(datasource.user));dataSource.setPassword(env.getRequiredProperty(datasource.password));return dataSource;
} 我的服务遇到的潜在问题是当来自DataSource的连接池的连接未能连接到数据库时它变得“不好”。 然后下一个问题是我的DataSource实现不会从连接池中删除这些“不良”连接。 它只是不断尝试使用它们。 幸运的是此修复非常简单。 当DataSource从连接池中检索连接时我需要指示DataSource测试连接。 如果此测试失败则连接将从池中删除并尝试建立新的连接。 我还需要为DataSource提供一个查询它可以用来测试连接。 最后并非绝对必要但对测试很有用默认情况下我的DataSource实现仅每30秒测试一次连接。 但是我的测试可以在不到30秒的时间内运行。 最终这段时间的长度并没有真正意义因此我添加了一个由属性文件提供的验证间隔。 这是我更新后的DataSource外观 Bean
public DataSource dataSource() {org.apache.tomcat.jdbc.pool.DataSource dataSource new org.apache.tomcat.jdbc.pool.DataSource();dataSource.setDriverClassName(env.getRequiredProperty(datasource.driver));dataSource.setUrl(env.getRequiredProperty(datasource.url));dataSource.setUsername(env.getRequiredProperty(datasource.user));dataSource.setPassword(env.getRequiredProperty(datasource.password));dataSource.setValidationQuery(SELECT 1);dataSource.setTestOnBorrow(true);dataSource.setValidationInterval(env.getRequiredProperty(datasource.validation.interval));return dataSource;
} 关于编写集成测试的最后一点说明。 最初我创建了一个测试配置文件该文件用于配置要在测试中使用的DataSource 。 但是这是不正确的。 问题是如果有人要从生产配置文件中删除我的修订但将其保留在测试配置文件中则我的测试仍会通过但是我的实际生产代码将再次受到我这段时间花的问题的侵害。定影 这是一个容易想象的错误。 因此在编写集成测试时请确保使用实际的生产配置文件。 自动化测试 因此即将结束。 我有一个测试用例可以准确地重现我在PROD中遇到的情况。 我有一个修复程序然后使我的测试从失败到通过。 但是所有这些工作的重点不仅是让我确信我的修订适用于下一个版本而且还适用于所有将来的版本。 Maven用户希望您已经熟悉surefire插件 。 或者至少希望您的DevOps团队已经设置了父pom以便在构建服务器上构建项目时每次提交都会花费您花时间编写的所有单元测试。 但是本文不是关于编写单元测试的而是关于编写集成测试的 。 集成测试套件的运行时间有时数小时通常比单元测试套件的时间不超过5-10分钟长得多。 集成测试通常也更容易波动。 虽然我在本文中编写的集成测试应该是稳定的-如果它破裂了应该引起关注-在连接到开发数据库时您不能总是100确信数据库将可用或测试数据将是正确的甚至是存在的。 因此失败的集成测试并不一定意味着代码不正确。 幸运的是Maven背后的人们已经解决了这个问题那就是带有故障安全插件 。 默认情况下surefire插件将查找Test之前或之后固定的类而failsafe插件将查找IT 集成测试之前或之后固定的类。 像所有Maven插件一样您可以配置插件应执行的目标。 这使您可以灵活地使每次代码提交都运行单元测试而集成测试仅在夜间构建时运行。 这也可以防止需要部署修补程序但不存在集成测试所依赖的资源的情况。 最后的想法 编写集成测试既耗时又困难。 它需要广泛考虑您的服务将如何与其他资源交互。 当您专门测试故障场景时此过程甚至更加困难且耗时这通常需要对测试所连接的资源进行更深入的控制并借鉴过去的经验和知识。 尽管花费了大量的时间和精力但这项投资将随着时间的推移多次收回投资。 只有通过自动测试才能提高对代码正确性的信心这对缩短开发反馈周期至关重要。 我在本文中使用的代码可以在这里找到 https : //github.com/wkorando/integration-test-example 。 翻译自: https://www.javacodegeeks.com/2016/10/blood-sweat-writing-automated-integration-tests-failure-scenarios.html
