On Mon, Jun 21, 2010 at 9:57 AM, Tuna Toksoz <tehl...@gmail.com> wrote:
> String comparison would get dramatic when we change the way we handle > column aliasses, for example. Any change would mean that all linq tests will > break. > > Tuna Toksöz > Eternal sunshine of the open source mind. > > http://devlicio.us/blogs/tuna_toksoz > http://tunatoksoz.com > http://twitter.com/tehlike > > > > > > On Mon, Jun 21, 2010 at 3:37 PM, Steve Strong <srstr...@gmail.com> wrote: > >> I've no doubt that it would be possible to go down this route, but it >> won't be quite that simple. Two things that spring to mind would be >> validation of parameter handling and checking of any client-side projections >> that are run against the data returned from NH. The first could be done, >> the second would be trickier since any client-side projections are compiled >> lambdas so pretty opaque. Of course, you could write separate tests just >> against those lambdas, passing in-memory data to them to check that they >> operate correctly,but it would certainly add complexity to the tests. >> >> Most of the NH test suite runs against the DB; the issue with the Linq >> ones was just the way that the data was getting inserted. Now that Fabio's >> refactored that I think the new test times are quite acceptable. >> >> Cheers, >> >> Steve >> >> >> On Mon, Jun 21, 2010 at 2:28 PM, Wenig, Stefan >> <stefan.we...@rubicon.eu>wrote: >> >>> Hi >>> >>> >>> >>> I’m not really following the efforts here, so this might be moot, but >>> here it is: We’re testing our re-store LINQ provider by translating LINQ >>> queries to SQL and then comparing actual and expected SQL in the tests. No >>> actual execution against the DB, except in one or two high-level integration >>> tests. >>> >>> >>> >>> You could do the same by emitting the generated HQL AST to an HQL string >>> and just comparing that to the expected HQL. There’s not really much use in >>> testing the actual HQL translation from the perspective of a LINQ provider, >>> is there? >>> >>> >>> >>> Stefan >>> >>> >>> >>> *From:* nhibernate-development@googlegroups.com [mailto: >>> nhibernate-developm...@googlegroups.com] *On Behalf Of *Steve Strong >>> *Sent:* Monday, June 21, 2010 11:46 AM >>> *To:* nhibernate-development@googlegroups.com >>> *Subject:* Re: [nhibernate-development] Re: Linq readonly test overboost >>> >>> >>> >>> Yeah, sorry about that file - it was built with a code generator, and >>> when I saw how big it was it I knew it had to be sorted out. But other >>> stuff always got in the way so it has lived for far longer than it should >>> have... >>> >>> On Sat, Jun 19, 2010 at 5:05 AM, Ricardo <rs...@usa.com> wrote: >>> >>> I did not test the new version of Linq tests, but the function >>> CreateNorthwindData with thousands lines of code seems to make visual >>> studio crawl and consume great amount of memory just to enter the >>> function. I spitted the function in many parts and the code run much >>> faster, 5 times or more. I think you could remove the data from C# >>> code and transfer to a xml file and read the data from a file. >>> >>> >>> On Jun 18, 1:39 am, Fabio Maulo <fabioma...@gmail.com> wrote: >>> > Hi all. >>> > I have refactorized the tests of Linq provider to fill DB before the >>> first >>> > fixture and drop it after the last fixture >>> >>> > NUnit featurehttp://www.nunit.org/index.php?p=setupFixture&r=2.5.5 >>> >>> > >>> > <http://www.nunit.org/index.php?p=setupFixture&r=2.5.5>With NUnit2.5+ >>> > testrunner the old tests crash (confirmed with Richard). >>> > >>> > To run Linq provider integration test for others dialect we have to >>> have 2 >>> > files per dialect: >>> > <dialect-name>LinqReadonlyCreateScript.sql >>> > <dialect-name>DialectLinqReadonlyDropScript.sql >>> > >>> > So far available only for MsSql2008Dialect. >>> > >>> > I'm going to update NUnit of our nhibernate\Tools\nunit to the last >>> version. >>> > >>> > -- >>> > Fabio Maulo >>> >>> >>> >> >> > -- Fabio Maulo
