I think that mirroring is not the the best solution in this scenario, and discontinuation announcement is not even the main reason, especially if you're planning to maintain the test environment only for limited amount of time.
Mirroring is a high-availability solution that was designed to provide hot/warm standby db in case of failure, or offload reporting to exact copy of the database (with snapshots). So the following properties of mirroring are simultaneously its' drawbacks:
- Both databases will be fully synchronized; you cannot select part of the db for mirroring, and may end up with high volumes of not needed data being transfered from principal database, reducing performance and increasing storage requirements for mirror.
- Changes in principal db are reflected instantaneously on mirror db, impacting production db and increasing network traffic (as opposed to single after-hours updates).
- You can only read from mirror db (through snaphot), so you won't be able to insert your own test data.
So if you don't need to update the test db from production environenment very often, the simplest solution would be to just manually restore full backups on your test db. You can even schedule your own COPY_ONLY backups and restores if you need your test db to be up to date.
You can also go with Merge Replication, which has these advantages over Mirroring:
- Synchronization schedules: it won't impact production db during working hours
- Filtering: you can choose what is being replicated
- Conflict resolution: you can apply your own logic for handling conflict, if you want to populate your db with own test data along with production data.
Snapshot Replication and Transactional Replication are also a viable options here.
Hope this helps, and let us know what you finally chose.