July 3, 2015 at 5:44 am
Hi there,
We are using Visual Studio 2012 with TFS and are looking at doing some Unit Testing on our TSQL code.
Am I right in thinking that TSQLT is the way to go, or am I missing something?
I had a quick look at http://sqlunit.sourceforge.net/[/url] but the last release note is dated 2006... which may not be a good sign. :doze:
Thanks
Eric
February 23, 2016 at 9:01 am
I think it's either tSQLt or the MS Unit Testing Framework.
tSQLt is all in T-SQL, it's easier to write tests for db people, and it includes more scaffolding that's DB specific.
the MS framework is in C#, but more integrated into VS. You do more work coding tests, but you'll build patterns quickly. If you're entirely in VS/TFS, you might find it easier to integrate into CI, but it's debatable.
Both work well.
February 23, 2016 at 9:57 am
Thanks Steve,
I indeed investigated tSQLt further and really liked it!
We use Visual Studio development and tSQLt integrates pretty well with it as it would with Redgate I'm sure.
Following best practice advice I found, I created Unit Tests projects and everything went really well...
...Unfortunately, our management does not believe in Automated testing! 🙁
February 23, 2016 at 5:49 pm
I know, lots of management doesn't. However devs still get value. Write the tests to exercise your code, so that when you alter it, you know if it still works.
February 24, 2016 at 2:14 am
Our management gets very upset if they find we spend time writing tests...
:doze:
February 24, 2016 at 3:16 am
Eric Mamet (2/24/2016)
Our management gets very upset if they find we spend time writing tests...:doze:
That is a little sad. Do they get upset when there are bugs in production code? I don't revisit the question often because I have accepted wholeheartedly that I must unit test any code I offer to another person, whether that be through an application at an engagement where I am being compensated with dollars or even on an online forum where I am offering free help or advice. I haven't met anyone in this business that categorically objects to unit testing code before it is shipped. Noone managing code delivery projects is fit for that role if they think unit testing is generally a waste of time.
Note that I am parsing the automating of unit testing out of that discussion however. Many managers simply won't pay for the effort to structure the unit tests so they can be run unattended and then maintain those tests as an integral part of the codebase and I get that part of the objection. It has a real cost. That said, those same managers often still expect bugs to be rare and code regressions to be non-existent.
If you start with the premise that unit testing is necessary before offering any warranty on your code, whether implied or explict, which I do, then why not use a tool to make those tests easier to write and reuse later? Seems silly to argue the converse at this point with the free, very robust tools we have at our disposal.
The MS Unit Test Framework was implemented in .NET but you don't need to know a lick of C# to write or run T-SQL Unit Tests. All unit tests are written 100% in T-SQL. The farthest away from T-SQL it might take you is when editing an XML config file to set the connection strings so the tests can reach your database. I work in MS Unit Test Projects all the time and it helps me write better code.
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
February 24, 2016 at 4:11 am
To be entirely honest, the objection is to Automated Unit Testing, not "manual" Unit testing.
So yes, there is a cost...
Maybe one day we will...
February 24, 2016 at 10:56 am
Write your tests so they can be run manually or automated.
It's a similar effort. You'll run manual tests many times anyway.
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply