I have no idea. I'll make a test and let you know. Pascal. jabber/gtalk: [email protected] msn: [email protected]
On Thu, Mar 5, 2009 at 05:59, Jonathan Pryor <[email protected]> wrote: > The #if removal fix has been committed to the testing-no-db branch. > > Any word on whether namespaces are still a problem for ReSharper? > > - Jon > > On Wed, 2009-03-04 at 23:14 +0100, Pascal Craponne wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
