1. I did this, because I use ReSharper to run unit tests from Visual Studio. And ReSharper is confused when all tests are in the same namespace, because it thinks they are the same.And all namespaces can be changed at once, with a smart find and replace, I think (as far as I remember, that's what I did)
2. Nice idea. I buy it (or take it if you give it for free). Pascal. jabber/gtalk: [email protected] msn: [email protected] On Wed, Mar 4, 2009 at 23:02, Jonathan Pryor <[email protected]> wrote: > It occurs to me that eventually we will want to add support for additional > SQL providers [0]. > > This isn't difficult, but it is annoying, as the tests are full of > conditional compilation logic to switch between the various providers, > change the namespace name, etc.: > > #if MYSQL > namespace Test_NUnit_MySql > #elif ORACLE > #if ODP > namespace Test_NUnit_OracleODP > #else > namespace Test_NUnit_Oracle > #endif > > Changing ~58 files to add new conditional compilation logic for > *each*provider doesn't strike me as a "fun time." > > Thus, two questions: > > 1. Is there any reason to change the namespace based on the assembly it's > going into? I don't understand why the above is done ~everywhere, just to > change the namespace of the tests, as they're going to be in separate > assemblies anyway. > > Ideally, we could remove this conditional compilation logic and just use > the same namespace for everything. > > 2. TestBase.cs is more complicated, as it wants to define the > XSqlConnection, XSqlCommand, and xint types for each provider. > > xint doesn't seem to actually be used, so it should be removed. > > XSqlConnection and XSqlCommand are a little harder to remove, but there is > a simple solution: partial classes. > > We could "abstract" out TestBase to depend upon members/properties based > upon interfaces instead of concrete types, e.g. code would assume the > presence of a `IDbConnection CreateConnection(string)' method, and use > CreateConnection(connStr) instead of `new XSqlConnection(connStr)'. > > Next, each Test project could supply the "other half" of TestBase, > providing the SQL provider-specific members which TestBase uses, e.g.: > > IDbConnection CreateConnection(string s) > { > return new SqliteConnection(s); > } > > This should allow removing most of the conditional logic within TestBase to > be removed, moving provider-specific logic into the provider-specific > projects. > > Thoughts? > > - Jon > > [0] Offhand, SQL Server Compact Edition and Mono.Data.Sqlite, if we don't > want to wholesale migrate from System.Data.SQLite to Mono.Data.Sqlite (see > previous email). > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "DbLinq" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/dblinq?hl=en -~----------~----~----~----~------~----~------~--~---
