search

improvedk / OrcaMDF

A C# parser for MDF files. Allows you to read tables, metadata and indexes from MDF files without it being attached to a running SQL Server instance.
http://improve.dk/archive/2011/05/03/introducing-orcamdf.aspx
GNU General Public License v3.0
181 stars 74 forks source link

Unit tests that depend on mdf files don't run #10

Open zippy1981 opened 11 years ago

zippy1981 commented 11 years ago

Many unit tests fail with a message like "'D:\Projects\OrcaMDF (GIT)\DBTests\6d104c11-7aa6-4241-b014-b83d93f636e7_SqlServer2008R2.ldf'" If you commit the test MDFs, I will modify the unit tests so they are loaded using relative paths.

improvedk commented 11 years ago

Actually the tests are performed by creating live databases on a SQL Server instance, detaching them and then testing them (more info here: http://improve.dk/avoiding-regressions-in-orcamdf-by-system-testing/). This makes it extremely easy to write tests, though somewhat slower to run them, and somewhat more cumbersome for others to run (welcome - you're the first external contributor! :)).

Right now it's hard coded to connect to a certain SQL instance and store them in the mentioned path. I've considered creating the databases one-off and then including the detached .MDF's with the SQL Server version in the name, making it much more portable and easy for others to run.

It would however be slightly more cumbersome to create new tests as you'd have to either modify one of the previous MDFs or create a new one altogether. At the benefit of speed, I think it's a valid tradeoff though.

zippy1981 commented 11 years ago

Ok I see that now. Well this problem could be solved easily via SQL Server 2012 LocalDB. What is the plan for transitioning to that in addition to (or as opposed) to SQL 2008R2 file format?

improvedk commented 11 years ago

Looking at things long term, I'd like to support all 2005+ formats as they're extremely similar, ignoring stuff like Columnstore indexes, TDE and such. However, for now I'd prefer to concentrate on SQL2008R2 as there are minor differences in the formats themselves - and especially so if you look at the DMVs.

Supporting minor differences in the engine could, for the most part, be done transparently and by strategizing parts here and there. Supporting multiple DMV versions would basically require an abstraction on top of the whole Database class, having different DMV sets for each version. It'd be possible, but will require a lot of effort that I would much rather put into having wider support for the 2008 R2 file format - especially seeing as the main purpose, for now, is in teaching. And for now, whether reading about the 2005 or 2012 format, it's basically the same.

In the shorter run, for the tests, I'm much more inclined to prebuild the MDFs and include them in the repo. They'll take up some space, but it's cheap and will make it way more portable and faster to run.