From a first look, the tests look fine and they do indeed seem to cover relevant tests cases, so thanks for the patch (I haven't verified them in detail though, e.g. whether theses test can indeed fail of if for some reason one will always pass even if it shouldn't etc...). However, I do have some comments:

I don't think adding the extra parameter "scene" to the core class MestTest is a good idea for the following reasons:

1. It adds complexity to the code / breaks the api. For instance:
   • documentation is missing in MeshTest,__init__(self) and in example usage in ModifiersTest is now outdated.
   • the parameter scene is not saved in self.scene like the other parameters
   • for the operators test, the parameter is now redundant.

but has no real benefits. For instance:

2. when you enter a wrong scene name, you get an exception 'context is incorrect', making writing tests and tracking errors just a little bit harder for no reason.
3. I thought the idea behind adding a different scene is to avoid extending tests along a different axis, but you still do it here, there is no benefits for extra scenes

So here are my suggestions:

1. Just extend tests along the Z-axis, so do exactly like was done in operators.blend. Collaboration should be easier this way, since you should be able to tell the difference between two blend files faster by just having to look at the file in orthographic mode, without having to switch through scenes / views.
2. Add comments to numerate the tests (e.g. add comment every 5 or 10 tests) because the framework identifies the tests by indices for now.
3. If you really really really want to create new scenes, then make the MeshTest scene agnostic (the same way it is collection agnostic). So you could simply detect the scene before applying the modifier/operator and then switch to it.

Please let me know what you think.