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 -~----------~----~----~----~------~----~------~--~---
