在使用kubebuilder构建脚手架并完成其中的Reconcile逻辑后，我们需要为其编写自动化测试，方便以后的开发，否则每次都要先用make run先把 k8s 环境跑起来，再用kubectl apply -f xxx.yaml提交给k8s，观察资源变化，这样会非常麻烦。

幸好controller runtime为我们提供了envtest框架，帮助我们对开发的operator进行测试，使用的测试框架为Ginkgo. 关于使用envtest对开发的operator进行crud类型的测试的文章已经有很多了，这里就不再详尽阐述了，具体可以参考这篇文章：https://lailin.xyz/post/operator-07-kubebuilder-test.html

需要注意的是，我们在使用envtest进行测试时，只是启动了一个API server和etcd数据库，我们的代码里面调用k8s API创建资源，在测试时只是向etcd数据库中写入记录，测试的过程中不会真正的去创建资源，比如创建pod，job等。这样测试起来比较方便，完全可以支持curd类型的测试。但是如果我们的operator比较复杂，而且你想测试你开发的operator一些更高级的功能时，envtest提供的这个API server和etcd 数据库就无法满足我们的需求了。

在开发 RHINO-Operator 的过程中，就遇到了这样的问题。项目中需要对Operator进行一个完整的测试，也就是说在测试的过程中必须要去创建pod, job等资源，因此envtest的环境无法为RHINO-Operator的测试提供完整的支持。

那么应该如何解决这个问题？既然envtest无法启动一个完整的k8s环境来测试我们的operator，那么是否可以将我们的operator放到已有的集群上进行测试，比如本地的minikube？

在互联网上寻找了很久也没有找到相关资料，最后从一个不起眼的角落里面找到了答案，参考微软k8s-cronjob-prescaler这个项目：Link

只需要将envtest.Environment中UseExistingCluster字段置为true，即可使用本地的k8s集群进行测试了。微软的这个项目是使用kind进行测试的，RHINO-Operator是使用minikube进行测试的，测试同样能够正常进行并顺利通过。

通过kubectl命令行可以看到，在测试过程中，的确创建了相应的资源，而不只是向数据库中写入数据：

测试也能正常通过：

RHINO-Operator的测试代码地址：Link