前面的文章中,我们介绍了如何在SpringBoot 中使用 MongoDB 的一些常用技巧。 那么,与使用其他数据库如 MySQL 一样,我们应该怎么来做 MongoDB的单元测试呢?
使用内嵌数据库的好处是不需要依赖于一个外部环境,如果每一次跑单元测试都需要依赖一个稳定的外部环境,那么这样的测试是极不稳定的。
为了更欢快的使用MongoDB,这里提供两种使用内嵌数据库做单元测试的方式。
开源地址
https://github.com/flapdoodle-oss/de.flapdoodle.embed.mongo
该组件的大致原理是,在当前环境中自动下载MongoDB并拉起进程,测试后再做关闭。
先演示一遍如何使用:
<dependency> <groupId>de.flapdoodle.embed</groupId> <artifactId>de.flapdoodle.embed.mongo</artifactId> <version>1.50.5</version> <scope>test</scope></dependency>
编写一个基础类:
@RunWith(SpringRunner.class)@SpringBootTest(classes = DemoBoot.class)@ActiveProfiles("test")public class BaseEmbededMongoTest {
private static final Logger logger = LoggerFactory.getLogger(BaseEmbededMongoTest.class); protected static final MongodStarter starter = MongodStarter.getDefaultInstance(); protected static MongodExecutable _mongodExe; protected static MongodProcess _mongod;
// 确保与配置一致 protected static final String host = "127.0.0.1"; protected static final int port = 27027;
@BeforeClass public static void setUp() throws Exception { _mongodExe = starter.prepare(new MongodConfigBuilder().version(Version.Main.PRODUCTION) .net(new Net(host, port, Network.localhostIsIPv6())).build()); _mongod = _mongodExe.start();
logger.info("mongod started on {}:{}", host, port); }
@AfterClass public static void tearDown() throws Exception { _mongod.stop(); _mongodExe.stop(); }}
BaseEmbededMongoTest 实现了:
接下来,让业务测试类继承于基础类:
public class BookServiceTest extends BaseEmbededMongoTest{
@Autowired private BookService bookService;
@Autowired private BookRepository bookRepository; ...
为了避免冲突,需要关闭 EmbeddedMongoAutoConfiguration。
@SpringBootApplication@EnableAutoConfiguration(exclude = { EmbeddedMongoAutoConfiguration.class})public class BootSampleMongo {...
最后一步,为了让业务代码能连接到自启动的MongoDB,需要做对应的配置:
在 src/test/resources 目录中编辑 application-test.properties
spring.data.mongodb.host=localhostspring.data.mongodb.port=27027spring.data.mongodb.database=test
执行业务测试类,可以看到一系列输出:
//下载Download PRODUCTION:Windows:B64 STARTDownload PRODUCTION:Windows:B64 DownloadSize: 147911698Download PRODUCTION:Windows:B64 0% 1% 2% 3% 4% 5% 6% 7% 8% 9% 10% 11%...//启动继承[mongod output] 2019-03-02T15:43:01.948+0800 I CONTROL [initandlisten] db version v3.2.1[mongod output] 2019-03-02T15:43:01.948+0800 I CONTROL [initandlisten] git version: a14d55980c2cdc565d4704a7e3ad37e4e535c1b2[mongod output] 2019-03-02T15:43:01.948+0800 I CONTROL [initandlisten] allocator: tcmalloc[mongod output] 2019-03-02T15:43:01.948+0800 I CONTROL [initandlisten] modules: none[mongod output] 2019-03-02T15:43:01.948+0800 I CONTROL [initandlisten] build environment:[mongod output] 2019-03-02T15:43:01.948+0800 I CONTROL [initandlisten] distmod: 2008plus[mongod output] 2019-03-02T15:43:01.948+0800 I CONTROL [initandlisten] distarch: x86_64[mongod output] 2019-03-02T15:43:01.948+0800 I CONTROL [initandlisten] target_arch: x86_64...[mongod output] 2019-03-02T15:43:02.070+0800 I NETWORK [initandlisten] waiting for connections on port 27027//单元测试...//关闭进程[mongod output] 2019-03-02T15:43:20.838+0800 I COMMAND [conn3] terminating, shutdown command received[mongod output] 2019-03-02T15:43:20.838+0800 I FTDC [conn3] Shutting down full-time diagnostic data capture[mongod output] 2019-03-02T15:43:20.846+0800 I CONTROL [conn3] now exiting[mongod output] 2019-03-02T15:43:20.846+0800 I NETWORK [conn3] shutdown: going to close listening sockets...[mongod output] 2019-03-02T15:43:20.846+0800 I NETWORK [conn3] closing listening socket: 456[mongod output] 2019-03-02T15:43:20.846+0800 I NETWORK [conn3] shutdown: going to flush diaglog...[mongod output] 2019-03-02T15:43:20.846+0800 I NETWORK [conn3] shutdown: going to close sockets...[mongod output] 2019-03-02T15:43:20.911+0800 I NETWORK [conn1] end connection 127.0.0.1:52319 (2 connections now open)[mongod output] 2019-03-02T15:43:20.911+0800 I STORAGE [conn3] WiredTigerKVEngine shutting down[mongod output] 2019-03-02T15:43:20.916+0800 I NETWORK [conn2] end connection 127.0.0.1:52320 (1 connection now open)[mongod output] 2019-03-02T15:43:20.943+0800 I STORAGE [conn3] shutdown: removing fs lock...[mongod output] 2019-03-02T15:43:20.943+0800 I CONTROL [conn3] dbexit: rc: 0
首次使用该组件时需要下载安装包,过程比较缓慢需要些耐心..
细心的同学可能注意到了,我们为什么要特别规避 EmbeddedMongoAutoConfiguration这个类呢?
在SpringBoot 官方文档中提到了 EmbeddedMongoAutoConfiguration,其作用主要是:
我们简单看一下实现:
@Configuration@EnableConfigurationProperties({ MongoProperties.class, EmbeddedMongoProperties.class })@AutoConfigureBefore(MongoAutoConfiguration.class)@ConditionalOnClass({ Mongo.class, MongodStarter.class })public class EmbeddedMongoAutoConfiguration { private final MongoProperties properties; private final EmbeddedMongoProperties embeddedProperties;
@Bean(initMethod = "start", destroyMethod = "stop") @ConditionalOnMissingBean public MongodExecutable embeddedMongoServer(IMongodConfig mongodConfig) throws IOException { Integer configuredPort = this.properties.getPort(); if (configuredPort == null || configuredPort == 0) { setEmbeddedPort(mongodConfig.net().getPort()); } MongodStarter mongodStarter = getMongodStarter(this.runtimeConfig); return mongodStarter.prepare(mongodConfig); }
不难猜到,该配置类已经完成了我们在单元测试中所需要的一切事情,
那为什么还需要BaseEmbededMongoTest?
答案在于,我们可能会对MongoDB的连接池做许多定制,如下面的代码:
@Configurationpublic void MongoConfig{ @Bean public MongoDbFactory mongoDbFactory(){ ... }}
类似这样的定制,会让MongoAutoConfiguration失效。
即SpringDataMongo 的初始化会先于Embeded实例的启动,导致失败。
通过自定义的实现则可以规避该问题,当然如果通过Profile设定也可以进行规避。
开源地址:
https://github.com/fakemongo/fongo
Fongo 是由 Fousquare 开发团队开源的一款真正的内存式MongoDB,非常适用于轻量级的单元测试。
Fongo 支持对 Java-Driver 的各种 CRUD 指令进行解析,并模拟数据在内存中的存储管理操作,可以认为其提供了一层 JavaDriver 的代理。
同时,该框架是线程安全的,所有的集合读写操作都能得到同步保护。
接下来是如何使用:
<!-- fongo face mongo --><dependency> <groupId>com.github.fakemongo</groupId> <artifactId>fongo</artifactId> <version>2.1.0</version> <scope>test</scope> <exclusions> <exclusion> <groupId>com.fasterxml.jackson.core</groupId> <artifactId>jackson-core</artifactId> </exclusion> <exclusion> <groupId>com.fasterxml.jackson.core</groupId> <artifactId>jackson-databind</artifactId> </exclusion> </exclusions></dependency>
fongo依赖于 jackson,可能与SpringBoot项目冲突,这里显示将其剔除。
编写一个基于Fongo的类:
@ActiveProfiles("test")@RunWith(SpringRunner.class)@SpringBootTest(classes = BootSampleMongo.class)@Import(TestConfig.class)public class BaseFongoTest {
}
这里使用 @Import 导入了一个TestConfig,用于初始化Fongo实例,如下:
@TestConfiguration@Profile("test")public class TestConfig extends AbstractMongoConfiguration {
@Autowired private Environment env;
@Override protected String getDatabaseName() { return env.getProperty("spring.data.mongodb.database", "test"); }
@Override public Mongo mongo() throws Exception { return new Fongo(getDatabaseName()).getMongo(); }
}
这样,通过继承于AbstractMongoConfiguration,可以省去配置MongoDbFactory之类的工作。 需要注意的是,如果业务代码做了一些连接池的定制,如MongoDbFactory/MongoTemplate的定义,则需要通过Profile进行隔离,避免在测试过程中出错:
@Configuration@Profile("prod")public class ProdMongoConfig {...
准备好上面的工作后,则可以用到业务测试代码上:
public class BookServiceTest extends BaseFongoTest{
@Autowired private BookService bookService;
@Autowired private BookRepository bookRepository;
至此,我们已经完成了Fongo 的使用。
https://dzone.com/articles/spring-boot-with-embedded-mongodb
https://github.com/flapdoodle-oss/de.flapdoodle.embed.mongo
https://github.com/fakemongo/fongo
随着MongoDB 在Web开发中的应用越来越广,许多配套的框架及工具也在逐步完善。
本文介绍了两种在SpringBoot 框架上使用内嵌MongoDB的方式,从简易性来看,个人更推荐Fongo的方案。
由于Fongo 更接近于H2(一种内存SQL数据库)的实现,整个测试过程中不需要开启MongoDB进程,也免去了远程下载软件的烦恼。 所有的操作均在内存中完成,会令整个测试更加的高效,然而其仅有的缺点是无法支持一些原生的 MongoDB管理命令(一般也不会用到)。
当然,读者也可以根据自己的需求自行选择。