Non-intuitive test data leads to proper constraints?

Sometimes I’ll have these interesting juxtapositions of two or more projects I’m working on at the same time. So what does Joe Celko have to do with the Visual Studio “Data Dude” (VSTSDD for short, I don’t know what the official acronym is yet) product? Well…


The first time I generated test data with VSTSDD, I was kind of surprised because it was SO random. Odd conglomerations of characters covering every bit of a data type’s value space. I was used to more “regular” test data, like…


I’d once worked on a VISA card system in the 80s that had about 100 or so completely made up test customers with real-sounding names. We’d run system tests (15 cycles if I remember correctly) that generated a few boxes of green-bar reports. BUT. The made up customers *had histories* so real that our users (who actually read the test reports) knew them better than our real customers. They could tell, for example that if “Fred Anderson” didn’t go over his credit-limit on cycle 12, there was a problem with our latest change on the test system. REALLY.


I couldn’t see how any users would remember test names that consisted of 25 “random edge-of-the-value-range characters”. I know you can write your own test data generator, but, I was a bit disappointed. At first.


So I’m reading Joe’s book “SQL Programming Style”. Rules 3.8.1 and 3.8.2: “Consider range constraints for numeric values.” And. “Consider LIKE and SIMILAR TO constraints for character values.” Hmmm…


So, although the test “names” aren’t particularly memorable, they exercise the ENTIRE allowed value space, preventing surprises in the case where someone has a name containing edge cases of characters, or numeric values at the end of the range. Forcing the needed constraints or procedure corrections. Great!


Because… (back to the book) “Look at the actual DDL and see how often you find this constraint. Programmers are lazy and do not bother with this level of details”.


Not any more, I guess.


I’d like to see how our users would have pronounced those character combinations and numeric values. Or they’d never encounter them because of proper constraints. Very cool.


Other articles

Imagine feeling confident enough to handle whatever your database throws at you.

With training and consulting from SQLskills, you’ll be able to solve big problems, elevate your team’s capacity, and take control of your data career.