After tests, no, it just doesn't work. My idea: we (I) could write a small tool to update all test files, and add #if'ed namespaces automatically. Pascal.
jabber/gtalk: [email protected] msn: [email protected] On Thu, Mar 5, 2009 at 08:09, Pascal Craponne <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
