Hacker News Reader

Comment by xtrumanx | Hacker News Reader

> Unit testing is also made easier by using an SQLite in memory database for several unit tests.

That doesn't sound like a good idea. You haven't tested the code that actually interacts with your PostgreSQL database. It seems that you're placing your trust in nHibernate to act exactly the same when working with SQLite or PostgreSQL.

If I were you, I'd run my integration tests against an actual PostgreSQL database and run my unit-tests against a mock repository. That way, your unit-tests test the actual logic of your app without being slowed down by trips to a database and your integration tests actually tests if your database calls work as expected.

How many tests have you currently got and how long do they take to run?

View on HN

> That doesn't sound like a good idea. You haven't tested the code that actually interacts with your PostgreSQL database. It seems that you're placing your trust in nHibernate to act exactly the same when working with SQLite or PostgreSQL.

Integration testing is definitely something I do, there's some code there to do a pretend game that runs through the motions as a final sanity check.

I've used a wrapper transaction around the unit test to do integration testing on the real database before (and a rollback after the test ends allows the schema to be left clean for the next test) but this time opted to try SQLite to see if it sped anything up.

In my experience so far, SQLite has been good at being a "mock repository" (it knows its schema from FluentNHibernate mappings), I don't need to hand-feed it what objects should be returned for some tests.

The caution you have about not using the exact database is a valid concern though; but one I don't mind right now, as the core logic I am really testing is responding as expected.

Various tests use no repository at all and are just using mock objects, it depends what's under test.

I currently have 105 tests, 20 second total runtime.

Once again, I haven't used SQLite in a very long time nor do I know anything about what your code looks like but there's a possibility that if you remove your calls to SQLite from your unit tests and use a mock repository, you could reduce that total run-time of your tests from 20 seconds to a second.

One of my current asp.net mvc projects has about 192 unit tests and has a total run-time around 2.3 seconds. Most of the time, the code I'm changing and working on doesn't interact with the database and so I can keep running all my unit-tests after every change to make sure I haven't broken anything. I wouldn't be running my unit-tests as regularly as I do now if I knew I'd have to wait 20 seconds each time.

Give trying using a mock for the test that involve SQLite when you find some free time. You may find the time saved to be worth it. I'd also suggest looking into dan_b's suggestion below; a one-line code change to go from in-memory to integration tests sounds interesting and if it works like I imagine it does, I think I'll be giving nHibernate another chance since my last disappointing attempt at using it.

Appreciate it, thanks. I definitely have tests that run instantly because they just use a mocked database, and ideally all of my tests would do that because I agree having them run instantly is so much better than waiting around.

I'm going to be more attentive to how long tests take from now on, and try and avoid a backed DB when possible. Thanks!

You can change your in-memory unit tests to integration tests with a one-line change using NHibernate.

Reply on news.ycombinator.com