November 10, 2009 at 2:19 pm
j.a.c (11/10/2009)
Ah technical debt... my group has it... lots of it that we are only starting to pay back.We do unit tests for most things and they are very useful. Except most of the issues that we find are due to load on the system and not any kind of logic errors...
And some of them can still be resolved before the system goes live and the users experience it. Problems with defects or performance in my view are usually the same, poor user experience.
But sometimes system loading by other processes can have an effect that we can't really anticipate or readily test..
CEWII
November 11, 2009 at 2:13 pm
Jeff Moden (11/9/2009)
Let me summarize my thoughts... every minute you spend testing during development will save an equal number of hours in post implementation debugging... maybe more.
Definitely more. By the time QA reports the bug and the person handing the bug out reviews it and it gets back to you and you remember what you were doing you still have to do the work that you would have had to do had you tested yourself and found the bug.
Were you the one that posted the article about the custom component for DB unit tests in VS?
P.S. Sorry for the run on.
November 11, 2009 at 2:35 pm
Steve Jones - Editor (11/10/2009)
I was stirring the pot a little, just to see how many people might agree. good to see most don't.Technical Debt - http://en.wikipedia.org/wiki/Technical_debt
A good read on it here: http://www.codinghorror.com/blog/archives/001230.html
Thanks for the links, Steve.
I have to worry about personal debt AND now technical debt? :w00t:
I think my technical debt is very small. There's always that "gotcha" in code that comes back to bite you in three years but I try to do good work and that reduces the technical debt.
November 11, 2009 at 3:44 pm
Steve Jones - Editor (11/10/2009)
You can't performance tune without some testing of how efficient things are. I guess I was wondering as well whether people actually think about testing beyond that. Jeff addressed some of that in his first comment, but most others haven't.Do you look for edge cases? In other programming, you can send in zeros, too much data in a parameter, etc., but do you do that in SQL?
For example, do you look at aggregations with and without NULLs in there? Do you examine what happens for character comparisons if you have numerics or dates in the fields? Do you look for implicit conversions that could cause issues?
Those are more what I think of when I consider unit tests. My feeling is that most developers aren't overly concerned with more than getting back the correct result set with their test data.
I often keep SQL Profiler running on the SPID that I've got for my Query Analyzer session, to give me some feedback as I develop.
The level of testing I do depends on how much time I have available and how important the results are; some projects do get pushed back so I can do more testing, some don't. I always test against full production data, as it's both larger and dirtier than most test data. In real life, on small SQL with large interlocking datasets, I rarely make up test rows, but I do deliberately look for data that causes errors.
For anything with arguments, sending in blanks or NULLs or (under) minimum values or (over) maximum values or 0 or other boundary conditions is easy.
As a general statement, SQL is just a high level computer language. It needs no more or less testing than any other similar high level computer language that fails to implement good internal error handling does.
November 11, 2009 at 4:22 pm
Fatal Exception Error (11/11/2009)
Jeff Moden (11/9/2009)
Let me summarize my thoughts... every minute you spend testing during development will save an equal number of hours in post implementation debugging... maybe more.
Definitely more. By the time QA reports the bug and the person handing the bug out reviews it and it gets back to you and you remember what you were doing you still have to do the work that you would have had to do had you tested yourself and found the bug.
Were you the one that posted the article about the custom component for DB unit tests in VS?
P.S. Sorry for the run on.
Nope... I wasn't the one. I am glad to see another person that "gets it" when it comes to testing.... there's no such thing as "if you have time"... if you like the company you work for, you have to make the time.
--Jeff Moden
Change is inevitable... Change for the better is not.
March 25, 2014 at 9:38 am
Jeff Moden (11/11/2009)
Fatal Exception Error (11/11/2009)
Jeff Moden (11/9/2009)
Let me summarize my thoughts... every minute you spend testing during development will save an equal number of hours in post implementation debugging... maybe more.
Definitely more. By the time QA reports the bug and the person handing the bug out reviews it and it gets back to you and you remember what you were doing you still have to do the work that you would have had to do had you tested yourself and found the bug.
Were you the one that posted the article about the custom component for DB unit tests in VS?
P.S. Sorry for the run on.
Nope... I wasn't the one. I am glad to see another person that "gets it" when it comes to testing.... there's no such thing as "if you have time"... if you like the company you work for, you have to make the time.
Aye, are we going to test this properly "If we have the time" is roughly equivalent to "Are you going to check the traffic at this junction before pulling out?", "If we ... " BANG.
I'm a DBA.
I'm not paid to solve problems. I'm paid to prevent them.
March 25, 2014 at 11:09 am
Premature optimization is the root of all evil!
I’m not a DBA. In fact, it’s been a long time since I’ve been a developer, but learning the little aphorism above, internalizing it and living by it VASTLY increased my productivity when I was.
After all, if it’s not correct, optimizing it only increases the velocity of the errors.
Generating more bad output faster is not generally considered to be constructive. At least not in my book.
March 25, 2014 at 12:38 pm
n.arley.dealey (3/25/2014)
Premature optimization is the root of all evil!I’m not a DBA. In fact, it’s been a long time since I’ve been a developer, but learning the little aphorism above, internalizing it and living by it VASTLY increased my productivity when I was.
After all, if it’s not correct, optimizing it only increases the velocity of the errors.
Generating more bad output faster is not generally considered to be constructive. At least not in my book.
Ignoring performance is also not a very smart thing to do.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
March 25, 2014 at 2:42 pm
n.arley.dealey (3/25/2014)
Premature optimization is the root of all evil!I’m not a DBA. In fact, it’s been a long time since I’ve been a developer, but learning the little aphorism above, internalizing it and living by it VASTLY increased my productivity when I was.
After all, if it’s not correct, optimizing it only increases the velocity of the errors.
Generating more bad output faster is not generally considered to be constructive. At least not in my book.
The trouble is that a lot of people don't understand the differences between "premature optimization" (which I agree is the root of all evil) and just writing good code.
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 9 posts - 31 through 38 (of 38 total)
You must be logged in to reply to this topic. Login to reply