Hi Jon, the idea is interesting, because I also have problems maintaining a VM with all the databases. Anyway I see several limitations: - This will require to rewrite all current tests - Making any small change (like the internal temporary objects naming) would require to change all tests - This makes any further optimization a pain. As an example, I rewrote the SQL generation engine last spring/summer, and even if the generated SQL is different is all ways from previous engines, the existing tests helped me validating the engine. Also (still my own story), some tests were complex, and I had no idea of what it would look like in SQL (I'm not an SQL expert at all, and yes, I rewrote an SQL generation engine :)), so until the engine worked I had no idea of what tests should look like. - SQL is very different from one vendor to another. A good example is how Skip() and Take() are handled in Oracle, SQL Server, and others.
But, beside all of this, DbLinq needs some new blood :) Yes, DbLinq tests need to be structured and validated, and I suggest a few preliminary moves: 1. Stefan Klinger (team member) was working on a Linux based VM with all databases. This would allow to validate that all tests still work. Stefan, if you read us, as far as I remember, you were close to finish. Could you distribute your VM? Can someone finish the job if you're too busy? 2. The test databases need to be checked: I suspect that some test fail because the database doesn't contain the right elements. 3. Jon, provide me a google code identifer, so I can add you to contributors (and I would be very pleased to) 4. Then you Jon can safely refactor the tests, after we have agreed on something more flexible (yes, I'm hard on flexibility :)) Regarding the tests, we could instead of a hard SQL string comparison (which will totally break all tests after first change), use regular expressions, so ignore internal names could be safely ignored, just like maybe tables or columns names (without ignoring their occurrence), whitespaces, comments, and so on? I also suggest to keep the current tests, but restructure them in real projects with real directories (currently they are all in the same folder, we could probably create new projets in new directories with links to shared files, instead of having all test projects in one folder). Last thing: all tests results are usually written at http://linq.to/db/Tests by me, so you can see the state of the art without running the tests. I probably forget a lot of things I want to say... But welcome Jon, and thanks for your help :) Pascal. jabber/gtalk: [email protected] msn: [email protected] On Mon, Feb 23, 2009 at 06:27, Jonathan Pryor <[email protected]> wrote: > First, an aside: is there an IRC channel to discuss DbLinq? > > I'm gratified that DbLinq contains unit tests for all the providers. > However, as a developer I dislike any tests that require an actually > running database, particularly in the case of DbLinq which is trying to > write a LINQ provider for 7 different databases. I do not look forward > to installing and configuring 7 different database systems, much less > running tests for all of them... > > For a project predicated upon databases, this does seem to be an odd > complaint. ;-) > > There is a method to my madness, though: "removing" the database > requirement would make it easier to run unit tests on systems that don't > have any databases (most useful from my perspective, as I want to get > some form of unit tests within Mono for System.Data.Linq). This should > also make life easier for new developers -- less "grunt" work to do (in > the form of setting up a DB server) before working on more interesting > development, etc. > > Note: I am NOT advocating that we drop the existing unit tests. > > What I am advocating is a layered testing strategy; for DbLinq, there > are logically 3 layers (at least) that can be tested (more or less) > separately: > > 1. IQueryable -> SQL command (to send to backend provider) > 2. IDataReader -> result sets > 3. Database -> IDataReader > > Strictly speaking, (3) is under the responsibility of the database > provider, not the LINQ provider, so can be ignored (e.g. there's no > reason for DbLinq to test SqlDataReader...). > > The existing unit tests would remain as "end-to-end" integration tests, > ensuring that things actually work when the more targeted tests > suggested above work. > > How would this work? > > I haven't looked at layer (2) yet, but layer (1) can be solved through > string comparisons on two "well known" types: DataContext.Log and > DbCommand.CommandText (as returned from DataContext.GetCommand). For > example, this works quite nicely on current DbLinq w/o requiring any > database support: > > DataContext context = new DataContext(new NullConnection()); > var foos = > from p in context.GetTable<Person>() > where p.FirstName == "foo" > select p; > var cmd = context.GetCommand(foos); > Assert.AreEqual(ExpectedText, cmd.CommandText); > > (NullConnection is a DbConnection subclass that does nothing on required > void-returning methods and throws an exception on all other methods. > It's enough to create a DataContext and elicit "interesting" behavior, > as seen above, without requiring a full-blown database.) > > DataContext.Log can be used for checking the SQL generated for e.g. > DataContext.ExecuteCommand() and DataContext.ExecuteQuery() (along with > LINQ expressions that are immediately evaluated, such as .Count()). > > A prototype of such an implementation is attached. > > Is this testing strategy something the DbLinq team would be interested > in implementing? > > Thanks, > - Jon > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
