Question

Currently our new database design is changing rapidly and I don’t always have time to keep up to date with the latest changes being made. Therefore I would like to create some basic integration tests that are basically sanity checks on my mappings against the database.

Here are a few of the things I’d like to accomplish in these tests:

1. Detect columns I have not defined in my mapping but exist in the database
2. Detect columns I have mapped but do NOT exist in the database
3. Detect columns that I have mapped where the data types between the database and my business objects no longer jive with each other
4. Detect column name changes between database and my mapping

I found the following article by Ayende but I just want to see what other people out there are doing to handle these sort of things. Basically I’m looking for simplified tests that cover a lot of my mappings but do not require me to write seperate queries for every business object in my mappings.

Answer 1

I’m happy with this test, that comes from the Ayende proposed one:

[Test]
        public void PerformSanityCheck()
        {
            foreach (var s in NHHelper.Instance.GetConfig().ClassMappings)
            {
                Console.WriteLine(" *************** " + s.MappedClass.Name);

                    NHHelper.Instance.CurrentSession.CreateQuery(string.Format("from {0} e", s.MappedClass.Name))
                        .SetFirstResult(0).SetMaxResults(50).List();

            }
        }

I’m using plain old query since this version comes from a very old project and I’m to lazy to update with QueryOver or Linq2NH or something else…
It basically ping all mapped entities configured and grasp some data too in order to see that all is ok. It does not care if some field exists in the table but not on the mapping, that can generate problem in persistence if not nullable.
I’m aware that Fabio Maulo has something eventually more accurate.
As a personal consideration, if you are thinking on improvement, I would try to implement such a strategy: since mapping are browsable by API, look for any explicit / implicit table declaration in the map, and ping it with the database using the standard schema helperclasses you have inside NH ( they eventually uses the ADO.NET schema classes, but they insulate all the configuration stuff we already did in NH itself) By playng a little with naming strategy we can achieve a one by one table field check list. Another improvement can be done by, in case of unmatching field, looking for a candidate by applying Levensthein Distance to all the available names and choosing one if some threshold requisites are satisfied. This of course is useless in class first scenarios when the DB schema are generated by NH itself.