Sure, of course you can take the one generated by the compiler. Special in this case it makes sence because of the fact that the data type just containes POD-types. But if you don't store the data itself I just remembered the hint from "Effective c++" to have them in place. And maybe I have to rethink about this hint next time :-).
Personally I prefer to use a shared pointer, so here my knowledge seems to be a little outdated.
Of course it is possible to do all these testing manually. But special for an ongoing refactoring people have to fight against a lot of scare caused by the facts, that they do not fully understand the legacy system or even do not know all supported features ( and I am sure the customer know them all when we break them down ). And things you don't know you cannot test and this is a scary fact in doing refactoring / redesign.
So building up automated tests can be one way to learn something about the current behaviour and document them by writing an easy to understand test.
You can take a look onto the QMl-Stuff, wich was completly rewritten for the 5.0 release. As far as I know some guy's are using this for 3D-application. You can also use GLSL-shadercode here. But don't ask me how good the performance is. I am just using QML for the UI for embedded.