Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase «««1234

Is Unit Testing Important? Expand / Collapse
Author
Message
Posted Tuesday, November 10, 2009 2:19 PM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Thursday, May 15, 2014 5:11 PM
Points: 6,032, Visits: 5,283
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
Post #816842
Posted Wednesday, November 11, 2009 2:13 PM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Tuesday, June 3, 2014 7:31 AM
Points: 155, Visits: 386
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.
Post #817449
Posted Wednesday, November 11, 2009 2:35 PM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Today @ 3:31 PM
Points: 2,566, Visits: 3,857
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?

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.
Post #817471
Posted Wednesday, November 11, 2009 3:44 PM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Today @ 2:04 PM
Points: 872, Visits: 2,409
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.
Post #817524
Posted Wednesday, November 11, 2009 4:22 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Today @ 8:47 PM
Points: 35,224, Visits: 31,683
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
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #817540
Posted Tuesday, March 25, 2014 9:38 AM


Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Yesterday @ 8:48 AM
Points: 300, Visits: 3,364
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.
Post #1554546
Posted Tuesday, March 25, 2014 11:09 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, March 25, 2014 11:08 AM
Points: 1, Visits: 0
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.
Post #1554598
Posted Tuesday, March 25, 2014 12:38 PM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 1:24 PM
Points: 5,440, Visits: 3,192
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!!!
Post #1554643
Posted Tuesday, March 25, 2014 2:42 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Today @ 8:47 PM
Points: 35,224, Visits: 31,683
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
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1554688
« Prev Topic | Next Topic »

Add to briefcase «««1234

Permissions Expand / Collapse