Client.Disconnect isn’t a great way to test this because that’s generally considered a cleanup/tear-down method that closes resources that are in-use and publishes some events like PoolClosed. It’s not really meant to be a transient state that you can “recover” from. If you want to test what happens when the server goes down, you can do this locally. I recommend looking into orchestration tools like mlaunch (http://blog.rueckstiess.com/mtools/mlaunch.html) to help you quickly start up replica sets locally.
- Shut down one or more nodes in the cluster. You can do this by connecting to the server directly and using
db.shutdownServer()(https://docs.mongodb.com/manual/reference/method/db.shutdownServer/) to test graceful shutdown procedure. - Force an election to test how the driver handles failover. This requires bringing down the primary node. You can do this either by suggestion (1) or running
rs.stepDown()on the primary (https://docs.mongodb.com/manual/reference/method/rs.stepDown/).