January 23, 2014 at 12:56 pm
Hi
I am new in SQL server so I need desperate help in doing Unit Testing for bunch of stored procedure that I wrote. So my manager told me to write some test cases and do some unit testing for the stored procedure. Please anybody could guide me or help me how to write or do unit testing ??
January 23, 2014 at 2:09 pm
Take a look at T-SQLT[/url]. That's a unit test framework for T-SQL. You can also check out SQL Test[/url]. That's a framework that Red Gate wrote around it.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
January 23, 2014 at 2:14 pm
saifmahatab (1/23/2014)
HiI am new in SQL server so I need desperate help in doing Unit Testing for bunch of stored procedure that I wrote. So my manager told me to write some test cases and do some unit testing for the stored procedure. Please anybody could guide me or help me how to write or do unit testing ??
I could be wrong but it seems to me that your manager is really asking for proof that [font="Arial Black"]YOU [/font]tested the code that you wrote. The fact that you have nothing in mind for that kind of proves that point.
You need to do the same thing you would for a book report in high school... go back through the code and document what the code does and doesn't do including which tables and columns it does it with. Writeup a set of instructions that identify the rows that someone needs to insert to test the functionality of your code.
Doing a "book report" is a good analogy here. Instead of reading the whole book and then trying to report on it, you should be testing each section of code as it is developed and writing down what the tests were that you did. That way, when your done with the code, two things will happen... your test cases will already be written and {drum roll please}, your code will actually work.;-)
--Jeff Moden
Change is inevitable... Change for the better is not.
January 23, 2014 at 5:15 pm
You might want to take a look at the following article:
How to Design, Build and Test a Dynamic Search Stored Procedure [/url]
Part of the process described therein is how I went about performing unit testing on each bit of the code as it was added. It is not nearly as exhaustive as Jeff has suggested in terms of recording the results. That is equally important for a beginner as he suggested.
My thought question: Have you ever been told that your query runs too fast?
My advice:
INDEXing a poor-performing query is like putting sugar on cat food. Yeah, it probably tastes better but are you sure you want to eat it?
The path of least resistance can be a slippery slope. Take care that fixing your fixes of fixes doesn't snowball and end up costing you more than fixing the root cause would have in the first place.
Need to UNPIVOT? Why not CROSS APPLY VALUES instead?[/url]
Since random numbers are too important to be left to chance, let's generate some![/url]
Learn to understand recursive CTEs by example.[/url]
[url url=http://www.sqlservercentral.com/articles/St
January 23, 2014 at 8:19 pm
saifmahatab (1/23/2014)
HiI am new in SQL server so I need desperate help in doing Unit Testing for bunch of stored procedure that I wrote. So my manager told me to write some test cases and do some unit testing for the stored procedure. Please anybody could guide me or help me how to write or do unit testing ??
Well, Unit Testing at the base level is just breaking your code up into units and testing each unit in isolation from the rest of the code. For a simple example, if you wrote 2 SELECT statements and union them together, then you could separate each SELECT statement and test them in isolation to ensure they behave exactly the way it's intended. That's where the SQL Framework someone mentioned comes into play. It's testing each piece of code in a isolated environment I do believe.
The problem with Unit Testing is that it can be very time consuming for the developer or engineer. Some down prioritize or only unit test in fragments. Where a great deal of others wait till completion and leave the testing in the QA tester hands in the software development world. But, good unit testing is golden if you can get in the practice. That's because it ensures that you as the developer, goes through every piece of what you developed with a fine comb. If you want to be known for precision, then unit testing is a must. If you want to be sloppy and get a lot done for the man, then you ignore unit testing and break or lose someones data. :hehe:
Test cases is documentation that describes everything you need to do in order to determine if the software or in your case, the procedure is working correctly. The best test cases IMHO are simple steps (meaning that any user to read the test case and follow) that has to be done to check a specific functionality of the procedure. I would google some examples because there is a great deal of documentation and methodologies out there for writing good test cases.
January 23, 2014 at 10:21 pm
xsevensinzx (1/23/2014)
...The problem with Unit Testing is that it can be very time consuming for the developer or engineer. Some down prioritize or only unit test in fragments. Where a great deal of others wait till completion and leave the testing in the QA tester hands in the software development world. But, good unit testing is golden if you can get in the practice. That's because it ensures that you as the developer, goes through every piece of what you developed with a fine comb. If you want to be known for precision, then unit testing is a must. If you want to be sloppy and get a lot done for the man, then you ignore unit testing and break or lose someones data. :hehe:
Test cases is documentation that describes everything you need to do in order to determine if the software or in your case, the procedure is working correctly.
...
Your first paragraph outlines why unit testing is the bane of development organizations everywhere, particularly if you happen to exist in a culture of "developers develop and testers test." Too often I see sloppy code passed to testers when even an incremental unit testing effort would have resulted in a much higher quality deliverable to the testing team, saving tons of retesting and rework.
I also agree with your second paragraph, in that your unit testing documentation should prove that you've made a reasonable effort and that the procedure is working correctly.
Contrast this with the proper mission statement of any reasonably good testing team:
Our (the testing team's) mission is to crash, corrupt, generate errors and demonstrate that the application we are testing does not meet the functionality requirements established by our customers before they do."
My thought question: Have you ever been told that your query runs too fast?
My advice:
INDEXing a poor-performing query is like putting sugar on cat food. Yeah, it probably tastes better but are you sure you want to eat it?
The path of least resistance can be a slippery slope. Take care that fixing your fixes of fixes doesn't snowball and end up costing you more than fixing the root cause would have in the first place.
Need to UNPIVOT? Why not CROSS APPLY VALUES instead?[/url]
Since random numbers are too important to be left to chance, let's generate some![/url]
Learn to understand recursive CTEs by example.[/url]
[url url=http://www.sqlservercentral.com/articles/St
January 23, 2014 at 10:49 pm
I shouldn't point the finger at the developer as much. There is also a great deal of pressure from those in management to push out results quicker at the sacrifice of quality. But yes, I've worked with a number of teams where unit testing was overlooked and sloppy code was pushed to QA.
Having worked in QA before jumping into development made me get into that practice of writing and testing my code in increments. That's why I highly suggest the practice if management allows it. 😎
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply