Using SqlLite for database tests

[John Simons]

I know this has previously been talked about and some people were opposed to use in memory sql lite db to run the database unittests. (sorry can't find the link to that discussion).

At the moment the major reason why we only have 2 working TeamCity agents is because we require a physical SQL server to run the tests, and it gets worse!
Because we are passing parameters on the TC build scripts eg:
-D:ar.dialect=NHibernate.Dialect.MySQL5Dialect -D:ar.connection.driver_class=NHibernate.Driver.MySqlDataDriver -D:ar.connection.connection_string.1="server=myserver;User ID=***;Password=***;database=castle_test1;" -D:ar.connection.connection_string.2="server=myserver;User ID=***;Password=***;database=castle_test2;" -D:ar.query.factory_class=NHibernate.Hql.Classic.ClassicQueryTranslatorFactory

we are restricting other agents from being able to chose their own database server, database names, UserId, and password.

Another problem is for users that want to run the tests local on their own workstations, to do this they have to pass this massive arguments list to nant.

Has anyone had success running all the db tests using SQLLite?
Should we aim to change  all the db tests to run against SQLLite, and as part of that get rid of all these parameters?

Cheers
John

---

Yahoo!7: Catch-up on your favourite Channel 7 TV shows easily, legally, and for free at PLUS7. Check it out.

[Markus Zywitza]

I already started to check whether it works and most tests pass. There
are some tests that can't pass (those marked with category MsSql) and
a few others that time out due to nested transactions.

From my point of view, we can change the DB to SqLite when we find a
way to use nested transactions with it.

-Markus

2010/2/3 John Simons <johnsi...@yahoo.com.au>:

> --
> You received this message because you are subscribed to the Google Groups
> "Castle Project Development List" group.
> To post to this group, send email to castle-pro...@googlegroups.com.
> To unsubscribe from this group, send email to
> castle-project-d...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/castle-project-devel?hl=en.
>

[John Simons]

I don't think SQLite supports distributed transactions across databases.
Is there any way to rewrite these tests so that we simulate that intend without having to do it for real?

Cheers John

-Markus

Cheers
John

__________________________________________________________________________________
Yahoo!7: Catch-up on your favourite Channel 7 TV shows easily, legally, and for free at PLUS7. www.tv.yahoo.com.au/plus7

[Markus Zywitza]

Sorry, but we only can ignore them. They are for the most part testing
the interaction of multiple SessionScopes and thus multiple
transactions (in the same thread). This is however something I
strongly discourage in real development, so I would be fine with
adding a category to them we can switch off in the CI build.

-Markus

2010/2/4 John Simons <johnsi...@yahoo.com.au>:

[James Curran]

On Thu, Feb 4, 2010 at 7:32 AM, Markus Zywitza <markus....@gmail.com> wrote:
so I would be fine with
> adding a category to them we can switch off in the CI build.

Being one (actually, two) of those potenial build agents which can't
run the MSSql tests, how would I say "Don't run that category on my
machine" ?

Truth,
James

[Markus Zywitza]

nunit-console.exe /exclude=MsSql

-Markus

2010/2/4 James Curran <james....@gmail.com>:

[James Curran]

On Thu, Feb 4, 2010 at 10:01 AM, Markus Zywitza
<markus....@gmail.com> wrote:
> nunit-console.exe /exclude=MsSql

But wouldn't that be part of a script that I don't have control over?

Truth,
James

[Markus Zywitza]

I'm about to change the buildscript and the problematic tests.

-Markus

2010/2/4 James Curran <james....@gmail.com>:

[John Simons]

Markus, are you also able to convert all the other projects that have db tests.

From the top of my head:

Monorail

Nhibernate integration

ActiveRecordIntegration

Cheers John

[Markus Zywitza]

I now changed AR to have a category called nosqlite for tests that
don't run with SQLite. Someone has to check why they are problematic,
but I don't have time for it right now.

There is also a batch file called builtwithsqlite.cmd for running that
configuration. The default config still tests against SQL-Server.

I also changed both CI-Tests to test against SQLite.

-Markus

2010/2/4 John Simons <johnsi...@yahoo.com.au>:

[Markus Zywitza]

Any idea anybody why the d****d thing now dies with a security
exception in nunit-console.exe?

-Markus

2010/2/5 Markus Zywitza <markus....@gmail.com>:

[Rafael Teixeira]

Just a guess, Sqlite needs to write your "relational" data to a file
(from the process you're running: NUnit in this case) so be sure your
database path is accessible from the build user account.

Rafael "Monoman" Teixeira
---------------------------------------
"To be creative means to be in love with life. You can be creative
only if you love life enough that you want to enhance its beauty, you
want to bring a little more music to it, a little more poetry to it, a
little more dance to it."
Osho

[Markus Zywitza]

The same dir in which NUnit creates the XML result file...

-Markus

2010/2/5 Rafael Teixeira <mon...@gmail.com>:

[John Simons]

Markus, just tried to run the unit tests from inside VS (using
resharper), and it still expects a physical sql server, are you
planning to make the sqllite the default?

Cheers
John

On Feb 6, 5:20 am, Markus Zywitza <markus.zywi...@gmail.com> wrote:
> The same dir in which NUnit creates the XML result file...
>
> -Markus
>

> 2010/2/5 Rafael Teixeira <mono...@gmail.com>:

>
> > Just a guess, Sqlite needs to write your "relational" data to a file
> > (from the process you're running: NUnit in this case) so be sure your
> > database path is accessible from the build user account.
>
> > Rafael "Monoman" Teixeira
> > ---------------------------------------
> > "To be creative means to be in love with life. You can be creative
> > only if you love life enough that you want to enhance its beauty, you
> > want to bring a little more music to it, a little more poetry to it, a
> > little more dance to it."
> > Osho
>

> > On Fri, Feb 5, 2010 at 2:27 PM, Markus Zywitza <markus.zywi...@gmail.com> wrote:
> >> Any idea anybody why the d****d thing now dies with a security
> >> exception in nunit-console.exe?
>
> >> -Markus
>

> >> 2010/2/5 Markus Zywitza <markus.zywi...@gmail.com>:

> >>> I now changed AR to have a category called nosqlite for tests that
> >>> don't run with SQLite. Someone has to check why they are problematic,
> >>> but I don't have time for it right now.
>
> >>> There is also a batch file called builtwithsqlite.cmd for running that
> >>> configuration. The default config still tests against SQL-Server.
>
> >>> I also changed both CI-Tests to test against SQLite.
>
> >>> -Markus
>

> >>> 2010/2/4 John Simons <johnsimons...@yahoo.com.au>:

> >>>> Markus, are you also able to convert all the other projects that have db
> >>>> tests.
> >>>> From the top of my head:
> >>>> Monorail
> >>>> Nhibernate integration
> >>>> ActiveRecordIntegration
>
> >>>> Cheers John

> >>>> On 05/02/2010, at 4:00, Markus Zywitza <markus.zywi...@gmail.com> wrote:
>
> >>>> I'm about to change the buildscript and the problematic tests.
>
> >>>> -Markus
>

> >>>> 2010/2/4 James Curran <james.cur...@gmail.com>:

>
> >>>> On Thu, Feb 4, 2010 at 10:01 AM, Markus Zywitza
>

> >> For more options, visit this group athttp://groups.google.com/group/castle-project-devel?hl=en.

[Markus Zywitza]

That's right. I only added the category nosqlite to the offending
tests, added a commented out section to app.config and a batch file
that executes the build with the options required for testing with
Sqlite.

Currently, my plan is to keep MsSql as primary database system for
testing due to a number of reasons:
- Testing with Sqlite is much slower than with MsSql
- 15 Tests simply don't work with Sqlite
- One LINQ test doesn't work with Sqlite indicating a problem in the
NHLinq implementation.

As a result, testing with SQLite is a workaround for the problems we
have with TeamCity, but not the ideal solution. The plan is to change
the most tests to use InMemoryTesting, and to test the rest only
explicitly. This will however take some time to change.

-Markus

2010/2/6 John Simons <johnsi...@yahoo.com.au>:

[Henry Conceição]

A good reason for keep the test with MsSql is that he is the main db
for AR's users. Maybe testing against sqlite or other in memory db can
hide some issues.

Cheers,
Henry Conceição

[Alex Henderson]

In my experience this hasn't been a problem (we work on a product that uses ActiveRecord with customers installing on Oracle, MsSql, MySql and Postgresql) .. all our integration tests (short of smoke tests for each db platform) run against Sqlite... never caused issues of that nature.

2010/2/11 Henry Conceição <henry.c...@gmail.com>