Testing unit test provider plugin
Is there any standard way to write integration tests for unit test provider with new ReSharper 6.1 SDK? Currently I have set of manual tests and want to do it automation and execute them on regular basis.
Please sign in to leave a comment.
Also I have some problems running SDK's driven unit tests with ReSharper's runner. Is it possible? Or I should use external test runner?
Alexander, there is assembly conflict when trying to run tests referencing assemblies with exaclty the same version as ReSharper itself. We're trying to resolve this issue, but due to CLR assembly resolving rules it's a bit tricky and sometimes not possible at all.
As for your original question: SDK doesn't provide any ways to run integration tests (if you mean running them with VS). However, I would recomend to create unit tests at least for MetadataExplorer and FileExplorer.
So, will there be an conflicts if version of SDK will be less than R# version?
Could you please show me some exmaples of your tests for FileExplorer and MetadataExplorer. I wrote some tests for FileExplorer but they is seem to me very ugly. My tests for FileExplorer is located there https://github.com/hazzik/ReSharper.XUnitTestRunner/blob/master/src/XUnitTestProvider.Tests/XunitFileExplorerTests.cs
Also I have another questions related to topic. Is it possible to instantiate type that represented by Psi.IClass or Psi.IAttributeInstance interfaces with builtin feature (something like VS's design time compilation).
>Alexander, there is assembly conflict when trying to run tests referencing assemblies with exaclty the same version as ReSharper itself. We're trying to resolve this issue, but due to CLR assembly resolving rules it's a bit tricky and sometimes not possible at all.
Are you tried to use bindig redirects?
Yes, we are using binding redirects, but they do not help in this case. The problem is in the same assemblies loaded in different AppDomains. If the assemblies are exactly the same, but loaded from different locations (this happens with SDK) they're not equal. And CLR loads assembly from domain's AppBase directory even when using Assembly.LoadFrom() with different path. Test runner fails in this case. We're considering changes in AppDomains usage, but it requires major changes in the whole test runner.