Steve Jones - SSC Editor (5/19/2015)
Jeff Moden (5/18/2015)
I did say that most UDFs would never be updated, not all but, let's ask the question.How many UDFs that were already in production have you actually updated?
A minority, but certainly some. However this applies to stored procedures as well. I chose a function to show that, but a proc could certainly be tested here.
I do see these evolve over time, short or long. Short, especially when they are doing something that is business related, and is subject to change. I've seen far, far too many people give me "rules" for automating something they do manually, only to realize that they have exceptions that come into play for their rules, but which are rare. Once they realize they've forgotten an exception, we need to handle it.
I wonder if 2014 SP1 and the "retro-accidents" that occurred in 2012 first made it to the street using such automation. 😀
To be honest, it would take MUCH more time to write the automation to do the tests than it would take to design the procs and related tables from the ground floor including the education of the project managers, QA, and the users. I'd also love to see what the automation would look like for the batch file processing we do.
Automation might be fine for UDFs, report procs, and simple crud but, unless someone takes the time to make a gold set and a total reset, I believe that automation would be mostly out of the question for what we do. Instead, we use run-time output of internal validation in the procs to "test" the procs. It's necessary anyway because we also have to produce auditable run time logs.
It also guarantees that a human looks at it instead of just a machine supposedly trained by humans. As they say "Humans makes mistakes but, if you really want to screw something up quickly, it takes a computer". 😛
--Jeff Moden
Change is inevitable... Change for the better is not.