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»»

An Example of Test-Driven Development Expand / Collapse
Author
Message
Posted Wednesday, May 06, 2009 10:45 AM


Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Wednesday, April 16, 2014 1:39 PM
Points: 388, Visits: 1,034
Hi Max,

Thanks for sharing your experiences and insight. We disagree, but I respect where you're coming from.

:{> Andy


Andy Leonard
CSO, Linchpin People
Follow me on Twitter: @AndyLeonard
Post #711293
Posted Wednesday, August 26, 2009 9:12 AM
SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Yesterday @ 9:00 AM
Points: 1,526, Visits: 1,834
Thanks, Andy,
I've been following along with these articles over the past few months, but didn't have the time to sit down and DO your examples. (Your explanations are GREAT, btw!)
We've been kicking around the idea of adding unit-testing for a few months now, but I have been so busy, I didn't want to slow down to write some. (No, we don't have the luxury of a Test Team right now.) Although I test the heck out of my code, I have really been running "functional" tests, not unit tests.

Building the tests from the very beginning looks like the way to discipline oneself to write them. I am now motivated to use this technique on new projects, going forward.

Thanks also for walking through building a solution from SSMS. I had never tried that and will try to use that in the immediate future.
Post #777594
Posted Monday, October 18, 2010 2:06 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Monday, March 12, 2012 3:41 PM
Points: 4, Visits: 23
good
Post #1006033
Posted Friday, October 29, 2010 1:29 AM


SSC-Enthusiastic

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

Group: General Forum Members
Last Login: Monday, March 10, 2014 1:08 AM
Points: 130, Visits: 795
Thanks for this good documented article. I definitely will get more into test driven development on SQL Server now. Actually in my old times as Cobol programmer (Hear, hear) this was the rule You do something and then you check possible return codes.
Post #1012845
Posted Friday, October 29, 2010 8:39 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Monday, January 06, 2014 6:58 PM
Points: 219, Visits: 823
Hey Andy,

Why would we want this: "Unit Test developed here will live on as a Regression Test for the remainder of this database's lifecycle".

What the purpose of keeping this test? If my database is gone, I will get a clear error message and know it is gone. I will spend no time troubleshooting, and this test will not help me in any way.

If the clear error message thrown by the server is suppressed, we should rather fix error handling - we need to do it anyway.

I suspect that this test would just bloat my project and slow everything down; it is not worth keeping it.

Can you please explain in which scenarios we are better off having this test than not having it?
Post #1013111
Posted Friday, October 29, 2010 10:07 AM


Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Wednesday, April 16, 2014 1:39 PM
Points: 388, Visits: 1,034
Hi Alex,

While I agree this adds to the amount of code that lives with the project, I disagree that it's bloat. For me, it's a question of how you want to manage change. This isn't the only way to do it. There are ways to manage change without using a process and those ways have advantages and disadvantages. There are change management processes and methodologies which, again, have their advantages and disadvantages. This is merely one process to manage change.

For me, regression test results are initially a Boolean and answer the question: "Did I just break something I fixed earlier?" Regression tests should grow over the life of the project, and I find a natural relationship between unit tests and regression tests. One way to express that relationship is this: "Current unit tests find their way into the regression testing scripts."

If this doesn't work for you - for any reason - don't use it. It works well for me.

:{> Andy


Andy Leonard
CSO, Linchpin People
Follow me on Twitter: @AndyLeonard
Post #1013194
Posted Friday, October 29, 2010 10:26 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Monday, January 06, 2014 6:58 PM
Points: 219, Visits: 823
Andy,

What will happen if you just drop this test? Is there any chance the problem you are testing will go unnoticed?

I don't think so. If your database is gone, every other test will surely fail as well, right?

So let us apply Occum's razor and remove this test - it does not add any value. The biggest problem with unit testing T-SQL is slowness, so getting rid of unnecessary tests is highly important.

Thanks.
Post #1013206
Posted Friday, October 29, 2010 10:37 AM


Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Wednesday, April 16, 2014 1:39 PM
Points: 388, Visits: 1,034
Hi Alex,

When it comes to testing, I prefer to apply mathematical proof methodologies over Occam. One anecdote about a logic test goes something like this:

Given: The pencil can move from the chair to the floor. Start by holding the pencil over the floor. How do you get the pencil to the floor?

The answer is "Place the pencil on the chair." We all know if we drop the pencil it will fall to the floor, but this isn't about what we all know; it's about proving what we all know.

So no, I respectfully disagree. I understand the tediousness of the code and appreciate that it will not appeal to everyone who reads this article. And I'm fine with you and others dsagreeing, but I maintain this is a viable and useful means to approach test-driven database development.

:{>


Andy Leonard
CSO, Linchpin People
Follow me on Twitter: @AndyLeonard
Post #1013214
Posted Friday, October 29, 2010 10:42 AM


SSCarpal Tunnel

SSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal Tunnel

Group: General Forum Members
Last Login: Today @ 9:47 PM
Points: 4,135, Visits: 5,855
What an utterly useless and pointless article!! Andy, you need to stick to something you know about, such as SSIS. Messing around with an actual database may well make your head explode!!
















Just kidding! Nice coverage of the basics of TDD!


Best,

Kevin G. Boles
SQL Server Consultant
SQL MVP 2007-2012
TheSQLGuru at GMail
Post #1013218
Posted Friday, October 29, 2010 10:48 AM


Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Wednesday, April 16, 2014 1:39 PM
Points: 388, Visits: 1,034
LOL Guru!

I think Alex is trying to tell me the same thing, although he's being much nicer about it than you!

:{>


Andy Leonard
CSO, Linchpin People
Follow me on Twitter: @AndyLeonard
Post #1013225
« Prev Topic | Next Topic »

Add to briefcase «««1234»»

Permissions Expand / Collapse