On Tue, 2010-04-06 at 19:44 +0200, Anders Holbøll wrote: > 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
Please no, if only for one reason: this won't be portable to Linux. So you'd be replacing a dead-simple solution (use the Northwind.db3 file in svn!) with a manual process, increasing the number of places for things to go horrifically wrong. > > 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. To make a decision, we need data. What are the tradeoffs? You've mentioned one pro (shorter test execution times) and I've listed one potential con (some tests will need rewriting). > > 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? It's really trivial: regenerate tests/Northwind.db3 from examples/DbLinq.SQLite.Example/sql/create_Northwind.sql and run the DbLinq.Sqlite_test.dll tests. Of 336 test cases, 45 fail when using the "examples" data set, all of which would need to be fixed during the migration back to that data set. Now, many of those are likely just asserting some number (and thus are easily updated). What I don't remember is which tests for which I couldn't find a query using the smaller examples set; sorry. > > [...] 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 As interesting as this is, who/what is creating/maintaining the TestResult.old.xml file? If your tool handles it, fine, but if *I* have to do it, forgetaboutit. Increasing manual steps (that I need to remember!) is not an option. 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.
