We can do even better in terms of testing by creating a test secret prior to the database migration. Then, at this stage, we can retrieve this test secret and its payload. This tests the database migration - but also is a good test of the barbican plugin migration, because the plugin would need to be migrated correctly in order for the secret to be decrypted properly. We can then delete the test secret.

There is a way to create a secret before the migration - and then test for its existence.

Also, we should probably do a test for creating a secret after adoption - that will test the operation of the worker.

It might be nice also to test the keystone-listener but that's going to involve a lot more setup.