MongoDB mock only clears listed collections

[ScottFreeCode]

The MongoDB mock will not clear the collections created by the service if they are not included in the defaults file.

It should clear any collections that the service created that are left out of the mock specification:

• if collections is not defined
• if collections is an empty array (really just a case of the below)
• if there are other collections mocked but additional ones are created by the service

[shanejansen]

I think this is possible but could be difficult to implement depending on the mock. Currently, mocks are reset using the values in their defaults file. So MySql will not delete databases outside its scope. Same for Rabbit queues and exchanges. I'd have to review Rabbit APIs to see if it's possible to get all queues + exchanges that exist in the instance. When designing TS, I made the assumption that services wouldn't be creating collections/databases/exchanges/queues outside the scope of the defaults file

[ScottFreeCode]

I guess the difference is I see collections as more like tables? (Since they're the subsets within the database that actually contain the records.)

With either mock I expect to name the DB as a whole in the defaults file (it's used in the connection string of my app, I am not absolutely certain about Mongo but I know for MySQL the app can't get to work on that DB unless it at least exists), then either:

• have tables/collections, with or without records, specified under that DB in the defaults file which will be the only stuff created (e.g. not using the app's migrations, as before the snapshot option); or:
• don't specify defaults beyond the DB name and let the app set up the contents (e.g. using migrations with the MySQL snapshot option, or taking advantage of Mongo's ability to create the collections used on the fly as needed).

(Rabbit is the odd one out as Touchstone has to be told which routing keys to listen on and publish to but I can otherwise let the app set the exchanges and queues up. In fact, in Rabbit this doesn't matter so much because messages either are consumed, or are in queues known by Touchstone, or are unneeded: old messages not known to Touchstone can't cause unexpected state the way old DB records can.)

[shanejansen]

That's a good point. I suppose it makes more sense to drop every collection in the db. I'll go ahead and add this to the 1.4 release