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 9:30 AM
Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: 2 days ago @ 11:09 PM
Points: 3,108, Visits: 11,502
Put simply, testing is part of development, so if you don’t unit test, the job is not done.

The ability to properly test is probably the most important skill for a developer to have.

Developers who do not unit test are incompetent and worthless.


Post #816638
Posted Tuesday, November 10, 2009 9:31 AM
Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: Today @ 2:48 PM
Points: 586, Visits: 3,571
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...
Post #816639
Posted Tuesday, November 10, 2009 9:36 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 4:06 PM
Points: 5,470, Visits: 3,257
My current contract is to resolve the Technical Debt. I guess thay can place a figure on it.

Gaz

-- Stop your grinnin' and drop your linen...they're everywhere!!!
Post #816644
Posted Tuesday, November 10, 2009 9:43 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Tuesday, August 3, 2010 12:18 PM
Points: 32, Visits: 122

I'd be willing to bet that the reason most people don't unit test is not because it's boring; it's because the boss wanted the solution yesterday. Boredom would be a luxury ... at least for the first half day or so!

Robb
Post #816653
Posted Tuesday, November 10, 2009 10:12 AM
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 @ 11:52 AM
Points: 876, Visits: 2,421
JustANumber (11/10/2009)
In spare moments we would generate the missing tests and, as you might have foreseen, found deficiencies in some stored procedures. Some were minor, some were critical. And someone, somewhere, was relying on inaccurate data, depending on the input parameters for the proc.


I have a few rules also.

Nothing is ever as simple as it appears.

Just because something appeared to work, doesn't mean it did work.

There is a vast amount of "working" code out there that returns invalid results at least some of the time, and very little of it is reconciled against other data that may be correct, or at least have different invalid results.

Just the other day, I saw an existing SQL stored procedure (which needed to return results in seconds) that never got tested on the case that one of the varchar parameters was fed in as blank. As it turns out, not only does it takes dozens of minutes to return results, but, presumably due to parameter sniffing, every subsequent call with even valid parameters takes dozens of minutes until the stored procedure gets recompiled.

This was a simple case of not testing boundary conditions, not believing that it would ever be called incorrectly, or both. Regrettably, it's common.
Post #816667
Posted Tuesday, November 10, 2009 11:55 AM


SSC-Enthusiastic

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

Group: General Forum Members
Last Login: Thursday, December 12, 2013 1:09 PM
Points: 111, Visits: 541
Michael Valentine Jones (11/10/2009)

Developers who do not unit test are incompetent...


I can get behind the idea that development isn't complete without unit testing because with unit testing, there is a spectrum between formal and informal. So there's room for pragmatism and common sense to fit the situation. As Wikipedia states (and I agree) "Its implementation can vary from being very manual (pencil and paper) to being formalized as part of build automation." In database development, it can include simply saving a .sql file containing test queries and other artifacts.







Bill Nicolich: www.SQLFave.com.
Daily tweet of what's new and interesting: AppendNow
Post #816725
Posted Tuesday, November 10, 2009 12:04 PM
SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: Monday, March 31, 2014 10:11 AM
Points: 431, Visits: 604
One of the testing approaches I implemented in my last position was as follows:
1) all code development for SQL was fully scripted in independent files in version control.
2) a single deployment script was written that could run against development, testing or QA. This reproduced the entire database structure along with lookup table data such as province/state, country, etc.
3) a second script was maintained with a small set of test data that covered most data conditions (new ones were added as we uncovered each new or unique situation).

This allowed us to run a full unit test at the SQL level, the business unit level or the UI level with a known data set and provided regression testing as we made changes. Of course, we could also run the tests against a full copy of the production data to confirm functionality against larger data sets.


Regards,
Michael Lato
Post #816735
Posted Tuesday, November 10, 2009 12:08 PM


SSC-Dedicated

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

Group: Administrators
Last Login: Today @ 3:46 PM
Points: 31,081, Visits: 15,527
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.







Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #816737
Posted Tuesday, November 10, 2009 12:41 PM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Thursday, December 20, 2012 1:03 PM
Points: 265, Visits: 589
What to unit test itself is a long learning process, much of it determined by anticipating problems. They depend on existing state of the app, frequency of upgrades, hardware capacities, software fixes, expected loads, and so on.

Both correctness of SQL and efficiency of SQL in development code can suffer from inappropriate unit tests. Developing the right combination for a given app is the crux of the problem in my experience. Otherwise unit tests can give another false sense of comfort.

The easiest unit tests and the most common ones I see are for user defined functions or relational features, such as referential integrity or check constraints. Beyond that, for me, it was entirely case-by-case basis. In almost all cases, we added the most interesting unit tests only after the application was in production for some time. We still keep adding more tests as we learn more ways it could fail or discover new edge conditions.
Post #816758
Posted Tuesday, November 10, 2009 1:36 PM
SSC-Enthusiastic

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

Group: General Forum Members
Last Login: Tuesday, September 16, 2014 10:48 AM
Points: 168, Visits: 132
Yes. To me, unit testing is the number one important in software development life cycle. This process helps finding bugs before it goes out the box and to ensure all the requirements in the specification are met.
Reducing error rate means increasing customers confidence in use of our products.
Post #816797
« Prev Topic | Next Topic »

Add to briefcase «««1234»»

Permissions Expand / Collapse