MySQL currently only tests one of the two supported providers
mikebeaton opened this issue · comments
Frans,
I managed to find an obscure bug to do with whether parameter names need prefixing within DbParameter itself. The bug doesn't affect existing Massive code, but it did mean I ended up with a bug in my own code which affected the Devart MySQL driver, but not the Oracle/MySQL driver and not any of the other four databases! The MySQL tests which I created only tested the Oracle/MySQL provider by default (you had to manually change the connection string to test the Devart driver) so I didn't notice for a while.
This has prompted me to create an additional project to test Devart (I share almost all the files, including the actual tests, using Visual Studio <Link> references) in order to run the same set of shared tests on both providers.
I was worried about adding needless complexity so I didn't do something like this originally. but now having been caught out by it, I think it must be sensible to include it.
Mike
There's an alternative: Using NUnit's feature to specify a parameter for tests through attributes, like this: https://www.nunit.org/index.php?p=testFixture&r=2.5 (scroll down to 'parameterized testfixtures)
So the testfixture (the test class) is annotated with two attributes, and the ctor receives 1 string argument. The string argument is the connectionStringName and which is passed to the ctor of the DynamicModel derived class, so it will choose between the two based on the input passed in by nunit.
I'm not sure this alternative is preferable over the one you already created: it saves a csproj in the solution, which is nice (as adding more test files in the future means you have to add them to the other csproj as well). Thoughts?
Yes, this is preferable! I will redo it this way - at some point over the next week or so - and make a new PR.
New PR on this issue, #315. I wondered what you thought about it. This approach as you suggested certainly seems preferable to me. There's obviously various options about exactly what gets passed in to the test constructor. I have used the provider name, at least for now, it looks reasonably clean. But re-reading your suggestion you were thinking of passing in the full connection string name. I'm also quite happy to make the minor changes to doing that instead, if you'd prefer that.
This pull request has two different obscure bugs, sorry.
One is that Oracle SetCommandSpecificProperties was always presupposing that only one DbCommand object type would occur in the entire program run... which is no longer true if we are testing two different providers in one run. I have commited a new version of Massive.Oracle.cs onto the pull request (91aec16) which uses dynamic to avoid this problem. (I think this version is actually possibly cleaner/better anyway, it uses a pattern found elsewhere in Massive.)
The other is that when running tests, I am seeing:
System.AppDomainUnloadedException: Attempted to access an unloaded AppDomain. This can happen if the test(s) started a thread but did not stop it. Make sure that all the threads started by the test(s) are stopped before completion.
as far as I am aware I was not seeing this before. I am looking into this one. Sorry about this.
(PS I should say: the tests have always been passing, since the original commit (of course!). But I have realised that these problems are there, anyway.)
Frans,
I have just reverted back to the current main branch version to test this, and I am still seeing the System.AppDomainUnloadedException when running tests.
So I am not quite sure what is going on here, but it seems this is not a problem with this pull request, so I'd like to tentatively propose this PR for your consideration again.
(As above, there really was one subtle Oracle bug, which only showed up for me when I added more tests in the same test harness; this is fixed by the 2nd commit.)
I think the appdomainunloaded exception is related to nunit (as you can't unload an appdomain normally). So I wouldn't worry about it.
👍
Parameterized approach has the problem that it does not transfer to xUnit, which might be a preferable test harness going forwards...
I think xUnit has the same feature, but of course it does things differently, so if someone wants to use xunit they have to refactor the code a bit. I find the xUnit+MS tactics a bit dirty tbh, they push nunit out like it doesn't exist and solely promote xunit as if other test frameworks don't work at all. I'll stick with nunit as it has always served me well. So no worries about that.
Merged
Yes, I was wrong, xUnit can do the equivalent thing using [Theory] plus [MemberData] (plus some light refactoring). (And I agree, I have never liked that MS approach - though they seem to be changing a lot recently! ;) )