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


An Example of Test-Driven Development


An Example of Test-Driven Development

Author
Message
Andy Leonard
Andy Leonard
SSCrazy
SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)

Group: General Forum Members
Points: 2387 Visits: 1101
Comments posted to this topic are about the item An Example of Test-Driven Development

Andy Leonard
Data Philosopher, Enterprise Data & Analytics
Calvin Lawson
Calvin Lawson
SSCrazy
SSCrazy (2.1K reputation)SSCrazy (2.1K reputation)SSCrazy (2.1K reputation)SSCrazy (2.1K reputation)SSCrazy (2.1K reputation)SSCrazy (2.1K reputation)SSCrazy (2.1K reputation)SSCrazy (2.1K reputation)

Group: General Forum Members
Points: 2124 Visits: 102
I like this a lot, it's a good demonstration of what it means to do test driven development. Everyone uses their own techniques, I tend to favor test harnesses that write to log tables/files. But this great; a good many projects fail because nobody can thoroughly test them.

Signature is NULL
Atif-ullah Sheikh
Atif-ullah Sheikh
SSCertifiable
SSCertifiable (5.1K reputation)SSCertifiable (5.1K reputation)SSCertifiable (5.1K reputation)SSCertifiable (5.1K reputation)SSCertifiable (5.1K reputation)SSCertifiable (5.1K reputation)SSCertifiable (5.1K reputation)SSCertifiable (5.1K reputation)

Group: General Forum Members
Points: 5124 Visits: 5204
Nice well demonstrated article. Still alot of confusions in my mind that WHY to through this long procedure of creating project, adding query files (if talk about the example in the article) . On can manually create a simple script file to accomplish the task.

But, I would say that I might be too far away from the necessities of the TD3. Once again, Nice Article.

----------------------------------------------------------------------------------------------------------------------------------------------------------------------

Sometimes, winning is not an issue but trying.

You can check my BLOG here


hodgy
hodgy
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: 2663 Visits: 596
I enjoyed this article; a good introduction to test-driven database development, something I have been looking to implement for quite some time.

I would be interested to see this expanded with some more practical examples, how you test complex stored procs, or triggers. Also, how do you deal with changing data from one environment to another?

Looking forward to more in this series.

Tom

Life: it twists and turns like a twisty turny thing

Rui Carvalho
Rui Carvalho
Grasshopper
Grasshopper (20 reputation)Grasshopper (20 reputation)Grasshopper (20 reputation)Grasshopper (20 reputation)Grasshopper (20 reputation)Grasshopper (20 reputation)Grasshopper (20 reputation)Grasshopper (20 reputation)

Group: General Forum Members
Points: 20 Visits: 31
I completely agree with the fact of writing sql scripts for deployment including tests and using sqlcmd is a very good practice, I use to do it in a similar way.
But what is the relation with test driven development? TDD means that you model your application in order to pass the tests you define and refactor it iteratively, that's not the same than making unit tests on your scripts.
Jack Corbett
  Jack Corbett
SSC-Forever
SSC-Forever (45K reputation)SSC-Forever (45K reputation)SSC-Forever (45K reputation)SSC-Forever (45K reputation)SSC-Forever (45K reputation)SSC-Forever (45K reputation)SSC-Forever (45K reputation)SSC-Forever (45K reputation)

Group: General Forum Members
Points: 45415 Visits: 14925
Loved the article. I really need to get more into Test-Driven Development.



Jack Corbett

Applications Developer

Don't let the good be the enemy of the best. -- Paul Fleming
At best you can say that one job may be more secure than another, but total job security is an illusion. -- Rod at work

Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question
How to Post Performance Problems
Crosstabs and Pivots or How to turn rows into columns Part 1
Crosstabs and Pivots or How to turn rows into columns Part 2
Bill Nicolich
Bill Nicolich
SSC-Addicted
SSC-Addicted (403 reputation)SSC-Addicted (403 reputation)SSC-Addicted (403 reputation)SSC-Addicted (403 reputation)SSC-Addicted (403 reputation)SSC-Addicted (403 reputation)SSC-Addicted (403 reputation)SSC-Addicted (403 reputation)

Group: General Forum Members
Points: 403 Visits: 543
Andy: Great article: Simple and effective. If people want to delve deeper, that's what the discussion forum is for!

Comparing notes:

Why consider the "test first" technique? 1. I find it helps me focus on one feature at a time, which in turn helps me break down the complexity of a project into many simple parts. So it helps me manage complexity. 2. It keeps testing from becoming a neglected afterthought. I can manage the risks in quality issues up front.

Why write reproducible tests? I feel more confident about making changes and adjustments if I can rerun the tests and get empirical evidence that things aren't broken. If I can efficiently make changes, I'm more agile.

I develop mostly in SQL Server 2000 right now as I'm sure others do, which doesn't have the try/catch feature. However, there are tools in 2000 for raising errors: RAISERROR ('User-defined Error in usp_ThisStoredProcedure.', 16, 1). custom code or a framework can offer reporting of test success and failure: EXEC tsu_failure @FailureMessage.

I've been using the TSQLUnit testing framework: http://tsqlunit.sourceforge.net/. TSQLUnit gives me the test suite logical grouping of tests with a setup and teardown for the group. Test code is written in stored procedures. The framework organizes the stored procedures through simple naming conventions. The framework gives some simple stored procedures to execute to run and manage the tests. Changes are rolled back at the conclusion of the tests.

I find that I use the unit tests mainly to set up and use test data (insert, update and delete test records) and test the functionality of stored procedures (did the stored procedure delete the test recordset as expected?).

I tend to not test all DDL (data definition language) statements such as whether or not certain objects exist except when necessary. For most of my DDL test needs, I've got the RedGate tool SQL Compare which compares every aspect of every object between my development and production. So, if the goal is to make sure nothing unexpected has changed, this tool does it for me in my environment where I don't require remote deployment.

As a developer, I feel more agile when I use test-driven development techniques and I think I produce better quality code. It can be done even in SQL Server 2000.

Bill Nicolich: www.SQLFave.com.
Daily tweet of what's new and interesting: AppendNow
SRDEV
SRDEV
SSC Rookie
SSC Rookie (25 reputation)SSC Rookie (25 reputation)SSC Rookie (25 reputation)SSC Rookie (25 reputation)SSC Rookie (25 reputation)SSC Rookie (25 reputation)SSC Rookie (25 reputation)SSC Rookie (25 reputation)

Group: General Forum Members
Points: 25 Visits: 28
I like the idea of Test Driven Development very much, but I'm not sure this is exactly how I would want it to go. Even in this simple example, the script that is created is actually an application to create the database. Instead I think I would be trying to keep it as lean as possible. Maybe do a check and print a result - and maybe fail. I can see where the script (application) created in the example could get to be bigger than the database project itself. If that permanently solved all the problems, that might work. But for continuous development, it means that new developers have to master not only the database, but the application. They would have to figure out how to modify the application to change the database.

Still, there is something here in "TD3", and the presentation of SS2005 features employed is interesting.
Andy Lennon
Andy Lennon
SSCommitted
SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)

Group: General Forum Members
Points: 1594 Visits: 826
This strikes me as a great approach to use for high-quality, (almost) self-documenting code.

I think the overhead of time and effort, at least when one is first implementing this technique, seriously compromises it's usefulness. That is to say, i probably don't have the patience to use this approach when i can just write stuff off-the-cuff, and i know for a fact that my boss does not have the patience.

Thanks for the article, Andy. I just don't think i'll ever be able to really use it. Crying
JJ B
JJ B
Ten Centuries
Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)

Group: General Forum Members
Points: 1165 Visits: 2860
What a well-written article. I like how you explain things. Also, your writing style is easy to read and the touch of humor keeps me engaged.

Alas, like others, I'm not convinced of the usefulness of this kind of approach. I'm not a lazy developer. I don't mind extra work for good value. For example, I document extensively even though it is no fun and does not directly affect the product. I just don't see the benefit of doing test driven development -- especially for database development.

But, at least now I feel I really understand the approach and how to implement it. If one is sold on the concept of test driven development to begin with, your approach and set of scripts makes a lot of sense. I will definitely read any other articles you publish in the future on the subject. Who knows, maybe I'll be converted. Thanks.
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