SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Is Unit Testing Important?


Is Unit Testing Important?

Author
Message
Elliott Whitlow
Elliott Whitlow
SSC-Insane
SSC-Insane (23K reputation)SSC-Insane (23K reputation)SSC-Insane (23K reputation)SSC-Insane (23K reputation)SSC-Insane (23K reputation)SSC-Insane (23K reputation)SSC-Insane (23K reputation)SSC-Insane (23K reputation)

Group: General Forum Members
Points: 23350 Visits: 5314
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
Fatal Exception Error
Fatal Exception Error
SSC Veteran
SSC Veteran (219 reputation)SSC Veteran (219 reputation)SSC Veteran (219 reputation)SSC Veteran (219 reputation)SSC Veteran (219 reputation)SSC Veteran (219 reputation)SSC Veteran (219 reputation)SSC Veteran (219 reputation)

Group: General Forum Members
Points: 219 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.
OCTom
OCTom
SSCarpal Tunnel
SSCarpal Tunnel (4.1K reputation)SSCarpal Tunnel (4.1K reputation)SSCarpal Tunnel (4.1K reputation)SSCarpal Tunnel (4.1K reputation)SSCarpal Tunnel (4.1K reputation)SSCarpal Tunnel (4.1K reputation)SSCarpal Tunnel (4.1K reputation)SSCarpal Tunnel (4.1K reputation)

Group: General Forum Members
Points: 4103 Visits: 4152
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.
Nadrek
Nadrek
SSCarpal Tunnel
SSCarpal Tunnel (4.4K reputation)SSCarpal Tunnel (4.4K reputation)SSCarpal Tunnel (4.4K reputation)SSCarpal Tunnel (4.4K reputation)SSCarpal Tunnel (4.4K reputation)SSCarpal Tunnel (4.4K reputation)SSCarpal Tunnel (4.4K reputation)SSCarpal Tunnel (4.4K reputation)

Group: General Forum Members
Points: 4416 Visits: 2741
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.
Jeff Moden
Jeff Moden
SSC Guru
SSC Guru (209K reputation)SSC Guru (209K reputation)SSC Guru (209K reputation)SSC Guru (209K reputation)SSC Guru (209K reputation)SSC Guru (209K reputation)SSC Guru (209K reputation)SSC Guru (209K reputation)

Group: General Forum Members
Points: 209701 Visits: 41973
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.
If you think its expensive to hire a professional to do the job, wait until you hire an amateur. -- Red Adair

Helpful Links:
How to post code problems
How to post performance problems
Forum FAQs
andrew gothard
andrew gothard
SSCrazy
SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)

Group: General Forum Members
Points: 2714 Visits: 5965
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.
n.arley.dealey
n.arley.dealey
Forum Newbie
Forum Newbie (7 reputation)Forum Newbie (7 reputation)Forum Newbie (7 reputation)Forum Newbie (7 reputation)Forum Newbie (7 reputation)Forum Newbie (7 reputation)Forum Newbie (7 reputation)Forum Newbie (7 reputation)

Group: General Forum Members
Points: 7 Visits: 30
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.
Gary Varga
Gary Varga
One Orange Chip
One Orange Chip (26K reputation)One Orange Chip (26K reputation)One Orange Chip (26K reputation)One Orange Chip (26K reputation)One Orange Chip (26K reputation)One Orange Chip (26K reputation)One Orange Chip (26K reputation)One Orange Chip (26K reputation)

Group: General Forum Members
Points: 26831 Visits: 6543
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!!!
Jeff Moden
Jeff Moden
SSC Guru
SSC Guru (209K reputation)SSC Guru (209K reputation)SSC Guru (209K reputation)SSC Guru (209K reputation)SSC Guru (209K reputation)SSC Guru (209K reputation)SSC Guru (209K reputation)SSC Guru (209K reputation)

Group: General Forum Members
Points: 209701 Visits: 41973
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.
If you think its expensive to hire a professional to do the job, wait until you hire an amateur. -- Red Adair

Helpful Links:
How to post code problems
How to post performance problems
Forum FAQs
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search