On Tue, Apr 6, 2010 at 22:31, Jonathan Pryor <[email protected]> wrote: > 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.
I'm obviously misunderstanding you, since "rm tests/Northwind.db3 ; sqlite3 -echo -init examples/DbLinq.SQLite.Example/sql/create_Northwind.sql -bail tests/Northwind.db3 .quit" seems to work fine on linux. I just thought it would be better working from a base of a text file that could be diff'ed against the other vendors. Clearly I was wrong. Of course it takes just over 10 minutes to load the instnwnd.SQLite.sql script, but wrapping the whole script in a "begin transaction"/"commit" cut it down to about a second. >> > 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). I think I have mentioned more than that pro and thought the strongest was the "debugability" (i.e. easier to see what is going wrong). And it seems that either way some tests need rewriting, since both data sets have had test written for it. Oh, well, guess I got to port some tests sql scripts. >> > 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 Okay. >> > [...] 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. I guess I do something like "copy TestResult,xml TestResult.old.xml" when I want to change the base (e.g. on check in), the script of course can't know when you want to do that. Personally I think it's easier than editing the .cs-files adding/removing Explicit-tags, but whatever. -- 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.
