July 23, 2015 at 3:32 pm
In the same way that men shaved without cutting their throats before the invention of safety razors quality code was written before the invention of unit tests.
July 23, 2015 at 3:38 pm
For .NET or Java, we have better tools for writing unit tests. Do we have good unit testing tools for SQL?
Thanks,
Naveen.
Every thought is a cause and every condition an effect
July 23, 2015 at 3:52 pm
Do we have good unit testing tools for SQL?
There is a tool by RedGate called SQL Test that builds on the tSQLt framework. It makes things much easier.
July 23, 2015 at 4:16 pm
cgeswein (7/23/2015)
Do we have good unit testing tools for SQL?
There is a tool by RedGate called SQL Test that builds on the tSQLt framework. It makes things much easier.
Yep tSQLt is basically a cross between nunit and moq, it will run tests (exec tSQLt.RunAll) and let you mock or in tSQLt terms fake a table.
July 23, 2015 at 7:18 pm
David.Poole (7/23/2015)
In the same way that men shaved without cutting their throats before the invention of safety razors quality code was written before the invention of unit tests.
Hmmmm.... maybe I'm mistaking what some folks refer to as "unit tests".
--Jeff Moden
Change is inevitable... Change for the better is not.
July 23, 2015 at 7:23 pm
I believe it is a freeware?
If yes, I can check with my org to install on Dev db.
Thanks,
Naveen.
Every thought is a cause and every condition an effect
July 24, 2015 at 2:11 am
tSQLt is free, the redgate sql test which is a ui around it isn't but you don't need to use it.
Here is a tutorial:
http://tsqlt.org/user-guide/tsqlt-tutorial/
If you get stuck there is a tSQLt google group where you can ask questions or on twitter with the #tSQLt tag
https://groups.google.com/forum/#!forum/tsqlt
ed
July 24, 2015 at 10:19 am
Jeff Moden (7/23/2015)
Hmmmm.... maybe I'm mistaking what some folks refer to as "unit tests".
OK bad phraseology. Before TDD type practices.
I can remember an impassioned debate about the adoption of TDD where a senior developer pointed out that quality code could and in fact had been produced prior to the existence of TDD.
My personal view is that the brilliance of an individual and their personal ability to develop quality code at record speed without unit tests is irrelevant. It is the ability of subsequent developers to change and add to that code base that matters.
The existence of tests may also prompt developers of future code to consider use cases for their creations that they would not normally have considered. How many security flaws consist of "a specially crafted package can cause...." in other words unexpected input can break an application. If you see a test for a buffer overrun then it is a prompt to make sure your code is not similarly afflicted. As soon as you see a test for a table missing a clustered index it is a prompt to make sure you aren't creating a similar potential problem.
July 24, 2015 at 12:48 pm
Ed Elliott (7/24/2015)
If you get stuck there is a tSQLt google group where you can ask questions or on twitter with the #tSQLt taghttps://groups.google.com/forum/#!forum/tsqlt
ed
Thanks Ed, that helps a lot
Thanks,
Naveen.
Every thought is a cause and every condition an effect
July 24, 2015 at 6:11 pm
David.Poole (7/24/2015)
Jeff Moden (7/23/2015)
Hmmmm.... maybe I'm mistaking what some folks refer to as "unit tests".OK bad phraseology. Before TDD type practices.
I can remember an impassioned debate about the adoption of TDD where a senior developer pointed out that quality code could and in fact had been produced prior to the existence of TDD.
My personal view is that the brilliance of an individual and their personal ability to develop quality code at record speed without unit tests is irrelevant. It is the ability of subsequent developers to change and add to that code base that matters.
The existence of tests may also prompt developers of future code to consider use cases for their creations that they would not normally have considered. How many security flaws consist of "a specially crafted package can cause...." in other words unexpected input can break an application. If you see a test for a buffer overrun then it is a prompt to make sure your code is not similarly afflicted. As soon as you see a test for a table missing a clustered index it is a prompt to make sure you aren't creating a similar potential problem.
Heh... what I meant to say is that your post alerted me to the fact that I wasn't thinking of "unit tests" as the others were. I'm right there with you. To be honest, that anyone that thingk NetOps is something new really hasn't been doing the job right to begin with and that things like TDD and TSQLT are for people that never really knew how to test their own code before sending it on. The latter is what I consider to be "unit testing" and, done properly, was (and still is) much more effective than TDD because the Developer is no longer limited to just the TDD outline.
--Jeff Moden
Change is inevitable... Change for the better is not.
July 25, 2015 at 2:42 am
I've been looking at the whole business requirements through to deliverable process.
I used to think I was quite good at testing and peer reviewing code.....until my then company hired a professional tester.
What I have learned is an age old lesson. People and process over tools and technology.
I feel that business analysts and testers need to pair up. As requirements are gathered the tester is thinking of how to test that the code that is yet to be will be tested.
Testers have a mentality that makes them good at what they do. They will think of test scenarios beyond those that a developer could be expected to imagine. The point that unit tests only test that the code does what the developer intended is missing the point. With the BA/Tester approach the developer gets a much broader set of code behaviours that the developer needs to consider.
With BDD frameworks such as Cucumber/Gherkin the tests are written in a form that a business person can understand. In effect you have a set of tests that describe the requirements and functionality of the application. These also act as documentation. There is no mystery black box legacy applications that everyone avoids like plague.
July 25, 2015 at 3:00 am
We have done Unit Test cases in few projects. I agree to your point where we associate the cost associated with it. Go for the TDD if your project has time and money for it.
The question is do we really need it all development scenarios... I would say No. Specially consider a small project where team size is about 5 developers. Out of which you will have a couple of freshers and the experienced ones also will have little idea. And then reluctance.
Most of the cases your requirements change and then you start catering to the change and then spending time in updating UTCs looks like a luxary.
I also feel it makes more sense to have UT in a rather enterprise level implementaion or a product development scenarios. This way you can control new versions test with previous version test cases (regression).
We are working in WCM environment, where it UT has limitations as it cannot test most scenarios.
July 25, 2015 at 8:38 am
David.Poole (7/25/2015)
I've been looking at the whole business requirements through to deliverable process.I used to think I was quite good at testing and peer reviewing code.....until my then company hired a professional tester.
What I have learned is an age old lesson. People and process over tools and technology.
I feel that business analysts and testers need to pair up. As requirements are gathered the tester is thinking of how to test that the code that is yet to be will be tested.
Testers have a mentality that makes them good at what they do. They will think of test scenarios beyond those that a developer could be expected to imagine. The point that unit tests only test that the code does what the developer intended is missing the point. With the BA/Tester approach the developer gets a much broader set of code behaviours that the developer needs to consider.
With BDD frameworks such as Cucumber/Gherkin the tests are written in a form that a business person can understand. In effect you have a set of tests that describe the requirements and functionality of the application. These also act as documentation. There is no mystery black box legacy applications that everyone avoids like plague.
No question and no argument there. We have a QA team and the things they think of to test is absolutely remarkable. The don't just test for "does it meet requirements". They also do some serious "negative" and non-happy-path testing that totally amazes me. As was once explained to me by a particularly good Lead QA member, "One of our most important jobs is to try to break things in ways that users or abhorrent data might BEFORE it gets into the hands of our users and customers." Yes, we sometimes (VERY rarely, though) make the decision to accept the risk of something they have found but at least we know ahead of time what could go wrong.
This is also why I don't generally support the notion of TDD. TDD falls into a "waterfall" category for me and Developers (or anyone else, for that matter) generally don't have the same test mentality as the folks in QA. It's not a fault on their part. Like you say, it's just a simple fact that folks in QA have that excellent brain for testing. When we start a project, QA starts writing test cases at the same time that Developers start working on code, which means no one is "waiting" for the next thing in these areas.
I've also found that a lot of people end up designing test code that's nearly or even more complicated than the code being testing. The worst part is that it frequently needs as much or more maintenance if requirements for the original code changes or are improved.
Unfortunately, in many companies, a lot of people have taken on the attitude that they don't actually need to test their own code at the unit level (whether the tests are written for the Development Phase or not) even for simple initial correctness because "QA will catch it" and that's a very, very expensive (both time and money-wise) mistake to make. For such companies, written unit testing methods during Development probably should be a requirement at least until they get their act together.
Getting back to the subject of the article, should unit tests be written? As with all else, I'll have to say again, "It Depends" and emphasize my agreement to "People and process over tools and technology."
--Jeff Moden
Change is inevitable... Change for the better is not.
July 25, 2015 at 9:09 am
Just out of curiosity how do people feel about the concept of rapid development as it relates to unit testing since the concept of small individual separate components is pretty much what unit testing is all about?
July 25, 2015 at 10:01 am
ZZartin (7/25/2015)
Just out of curiosity how do people feel about the concept of rapid development as it relates to unit testing since the concept of small individual separate components is pretty much what unit testing is all about?
My goal during "rapid development" exercises is to prevent them from becoming "rabid development" exercises. Nothing changes during rapid development in our shop (and is documented in our operating procedures) except that certain resources are dedicated to quickly moving code. It's still tested by the Developer during development, it still goes through a peer review, it still goes through QA, and it still goes through UAT. The only difference is the speed at which those things happen due to the dedicated resources. This doesn't happen for us often because the only time we have the urgent need for rapid development is if a fault somehow made it to production and, as David Poole says, because of the "people and the process" that we normally use, such urgencies are quite rare.
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 15 posts - 31 through 45 (of 86 total)
You must be logged in to reply to this topic. Login to reply