Here’s a little secret. Slow tests really annoy me. You know, when you run a single test that takes 10+ seconds or a small set of tests takes 3 minutes. One of the many reasons I really like unit testing is getting a measure on my progress quickly. That enables continuing to make quick progress or quickly fixing the problem. That falls apart when tests run slow. For example, my tests on one particular project where one test takes 10 seconds. Granted its an integration test and all subsequent tests run much faster. Still I would like to improve that.
I know exactly what the problem is; I created the problem. On purpose. It’s resetting my database schema back to the version I want using FluentMigrator by stepping down to version zero and then migrating back up. I want a clean database when I run integration tests. The thing is there is almost a solution for the problem: FluentMigrator.
My database is sql server; but if I was running sqlite in memory, the tests should be really fast. This leads to the debate inside my head. You see, sqlite doesn’t support foreign keys which my sql schema uses. On top of that, It’s throwing an error in the sqlite generator when you try to create a foreign key. But should it? On one hand, it’s not supported in sqlite so it kind of makes sense. It would be nice to gracefully handle it though for situations where you might want some flexibility with your back end. Like my integration testing scenario. Before I ask, I know it’s thin ice to perform integration testing against a different db than your target product db. Now, what do you think? I’m thinking towards allowing both but defaulting to throwing an error with FK’s in sqlite.
Maybe something like this to avoid the FK error with sqlite?
1: Create.ForeignKey("FK_Approvals_UserId").FromTable("Approvals").ForeignColumn("UserId").ToTable("Users").PrimaryColumn("Id").SoftFail();
-j