On Fri, Mar 26, 2010 at 16:07, Jonathan Pryor <[email protected]> wrote: > Of course we'd still need the .db3 binary blob. How else do we easily > test SQLite? ;-) The same way that every other vendor is tested, by downloading the software and generating the database from the sql-script. Specifically: del tests\northwind.db3 lib\sqlite3.exe -echo -init examples\DbLinq.SQLite.Example\sql\create_Northwind.sql -bail tests\northwind.db3 .quit
> That said, *please*, go forth and do it if you feel that strongly. It > will require two things, though: I don't feel it strongly, but I do think that *a* decision should be made. But I'm now working from the assumption that the examples-scripts are the right ones. > 1. Updating documentation so that people attempting to run the unit > tests can actually have them pass. Yep. I'm trying to get a handle on it before documenting it. I guess the process have two steps: doing the initial setup and running the tests. The last part might be in form of a bat-file. > 2. Updating the unit tests themselves so that they pass. The problem is more the tests that succeed but shouldn't. I've been looking a bit on the tests that fail for oracle, but succeed for other vendors as those i guess are the easy wins. Some of those, e.g. "ReadTest.D09_Products_LetterP_Take5" (which is hardcoded by vendor and allows to much since it uses "Assert.Greater" and not "Assert.Equals") will probably need some changes to the tests. > This is by far the bigger issue, as I know many of the tests I wrote > will only work against the "full" Northwind dataset (and thus will need > fixing), [...] Do you remember what tests or test classes that would be so I could check? >> ...but having few data, makes it easier to extend the schema. > > I don't think extending the schema will be that easy, considering that > any such "extensions" would need to be done to ~6 different databases, > with subtly different SQL dialects, and (currently) no one has access to > all of the actual databases... Then I wonder how I created the updated Tests wiki-page :) Generating the sql-scripts from a c# object model (without using dblinq) is for the future. >> Ok, so the tests currently marked Explicit should just be read as >> regular failing tests and are todo. > Correct. Or they're tests that the DB can't support [..] Ok, thanks for clearing it up my misconception. > [...] I outlined two approaches (TestResult.xml comparison, > the current [Explicit] setup). There are likely others. What we do > doesn't matter so much as that the solution be FAST and require MINIMAL > additional work from the dev. I agree. I've been playing with the test-reporter to make it generate something useful. I think this gives a rather good overview (needs to be documented, e.g. by using Mono.Options, but: trb: test-result-base, tr: test-result (current), ho: html-output, oc: only-changes such that only tests that changed between the two runs are shown): TestReporter.exe -trb ..\..\..\..\..\TestResult.old.xml -tr ..\..\..\..\..\TestResult.xml -ho ..\..\..\..\..\..\wiki\Tests.wiki.html -oc -- Anders -- 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.
