October 9, 2017 at 12:52 pm
jonathan.crawford - Monday, October 9, 2017 6:45 AMblog 24112 - Monday, October 9, 2017 12:16 AMI've been designing, writing, implementing and supporting complete accounting systems for 30 years. When I first started using SQL, I experimented a bit with some of its capabilities. I quickly discovered that, although there were a lot of things I could do in the DB, it made those functions invisible when looking at the program code. i.e. by looking at the program, I couldn't actually see what was being done with or to the data. Triggers are a great example. I found that intolerable and a huge opportunity for making major logic errors. Using SQL for things I prefer to handle in the program code is perhaps why some people are evangelists for writing "automated tests".For my part, I choose to limit my use of SQL to mainly the CRUD operations, retrieving and sorting sets, simple joins and views, and using foreign keys for update and delete purposes where it makes sense. I do test the code, and while I have occasionally missed minor errors, they have never created a big problem and they have always been easily fixable.
I have never written tests and have never had an issue where I think having tests would have been worthwhile. The time and effort to write and maintain them would simply be a massive waste of time based on my experience.
Keeping things as simple as possible, without sacrificing functionality and ease of use for the user, is a central tenet of my programming philosophy. In my opinion, a lot of the "modern coding practices" (like testing) are mainly a result of poor programming methodologies, design choices and quality control. Of course, buzzwords and "the next big thing" also make a lot of money for the professional speakers, seminar producers and industry media.
In my situation, writing tests would cost a lot in productivity for a very negligible (if any) improvement in quality. Of course, YMMV.
And what happens when you hand your code off to me, who doesn't have the benefit of your programming experience and the wisdom to choose when to code simply and when not to? How will I make sure that everything still works the way it's supposed to? How will I reassure management?
If you're at least a somewhat competent programmer, you will be able to see what the program is doing by looking at the code without having to hunt through the DB trying to find why a particular value in the program isn't what actually gets saved in the DB...
As to how you reassure management... Systems that work day in and day out without needing constant band-aids, baling wire, duct tape, glue, fire extinguishers and crises management tend to do that. If you can't do that, well, write tests... 🙂
October 10, 2017 at 7:20 pm
blog 24112 - Monday, October 9, 2017 12:52 PMIf you're at least a somewhat competent programmer, you will be able to see what the program is doing by looking at the code without having to hunt through the DB trying to find why a particular value in the program isn't what actually gets saved in the DB...As to how you reassure management... Systems that work day in and day out without needing constant band-aids, baling wire, duct tape, glue, fire extinguishers and crises management tend to do that. If you can't do that, well, write tests... 🙂
that's a nice cane you got there, Dr. House. If only I weren't some halfwit physician who learned his practice from the back of a cereal box, I'd realize that I don't need blood tests, medical records, transfusions or diagnostics. I'd just pop some pills like you and triumphantly declare, "it's syphilis!"
methinks perhaps saying that if someone is "somewhat competent" and can write "systems that work" then they don't need testing is a bit disingenuous. Things only work until they don't work. Building habits that work even if they require more effort to do so seems prudent, not foolhardy.
-------------------------------------------------------------------------------------------------------------------------------------
Please follow Best Practices For Posting On Forums to receive quicker and higher quality responses
October 11, 2017 at 8:30 am
jonathan.crawford - Tuesday, October 10, 2017 7:20 PMthat's a nice cane you got there, Dr. House. If only I weren't some halfwit physician who learned his practice from the back of a cereal box, I'd realize that I don't need blood tests, medical records, transfusions or diagnostics. I'd just pop some pills like you and triumphantly declare, "it's syphilis!"methinks perhaps saying that if someone is "somewhat competent" and can write "systems that work" then they don't need testing is a bit disingenuous. Things only work until they don't work. Building habits that work even if they require more effort to do so seems prudent, not foolhardy.
Yes... 🙂 It was a little more sarcastic than necessary. Just my sense of humor.
While manual testing has always worked fine for me, my situation is probably a bit unique. If you're part of a team and working on just a part of the whole, maybe automated tests work well there. Although it still seems like writing a test that covered every possibility would be quite difficult, prone to failure when the code changed and quite labor intensive.
October 11, 2017 at 8:33 am
jonathan.crawford - Tuesday, October 10, 2017 7:20 PMmethinks perhaps saying that if someone is "somewhat competent" and can write "systems that work" then they don't need testing is a bit disingenuous. Things only work until they don't work. Building habits that work even if they require more effort to do so seems prudent, not foolhardy.
I'd add that many of these habits only take more time as you get used to them. After that they are a part of your routine and don't slow you down.
October 17, 2017 at 7:33 am
Steve Jones - SSC Editor - Thursday, October 5, 2017 9:30 PMComments posted to this topic are about the item Why Don't You Unit Test Code?
Just getting started implementing tSQLt at a new shop. Running into some challenges:
1. You can't fake tables that are referenced by schema-bound views. These are used extensively here
2. You can't easily unit test code that makes database changes (e.g. a sliding window proc). Or I just can't figure out how to do it in an automated fashion
3. Unit testing SSIS packages is no picnic. For anything beyond a simple read some data, clean it, write it somewhere (faking inputs and outputs) it gets real complicated, real fast. (not to mention that the unit test machinery needs to know how to execute a parameterized package, monitor it to completion, then check the results).
4. Unit testing .NET code that executes packages and procs and ad-hoc queries is a big challenge.
Even with these kinds of issues, the discipline of writing unit tests has already exposed edge cases where things go wrong
Viewing 5 posts - 16 through 19 (of 19 total)
You must be logged in to reply to this topic. Login to reply