August 19, 2019 at 6:33 pm
Not really. Saying that I don't think you understand, is not an ad hominem attack. I also didn't mean it as an insult, just trying to figure out where you're misunderstanding is coming from so that I can help you understand. Your very first post mentioned your viewpoint from a C# programming level, but none of your posts describe any SQL development experience. Twice I've mentioned tSQLt. You may want to take a look, it might help. My apologies if it seemed like I was attacking you. Certainly wasn't my intention.
August 19, 2019 at 6:59 pm
Not really. Saying that I don't think you understand, is not an ad hominem attack. I also didn't mean it as an insult, just trying to figure out where you're misunderstanding is coming from so that I can help you understand. Your very first post mentioned your viewpoint from a C# programming level, but none of your posts describe any SQL development experience. Twice I've mentioned tSQLt. You may want to take a look, it might help. My apologies if it seemed like I was attacking you. Certainly wasn't my intention.
A few pages back Jeff Moden wrote:
And, that's why I don't care for what people are calling "Unit Tests". It doesn't make sense to have two pieces of code to maintain and get both right.
I agree 1,000% with this
Aus dem Paradies, das Cantor uns geschaffen, soll uns niemand vertreiben können
August 19, 2019 at 7:25 pm
A few pages back Jeff Moden wrote:
And, that's why I don't care for what people are calling "Unit Tests". It doesn't make sense to have two pieces of code to maintain and get both right.
I agree 1,000% with this
Appeal to authority? Just kidding!
It's definitely more code to deal with, there's no denying that. Whether it's beneficial is another matter. Hopefully it's keeping people from making mistakes as well as documenting intended behavior. I have no doubts that Jeff Moden has no issues creating great code without unit tests. I suspect that if he spent some time with it though (maybe he has, I don't really know), and he had people who were regularly changing his code, he might find some value in it.
August 19, 2019 at 7:27 pm
chris geswein wrote:Not really. Saying that I don't think you understand, is not an ad hominem attack. I also didn't mean it as an insult, just trying to figure out where you're misunderstanding is coming from so that I can help you understand. Your very first post mentioned your viewpoint from a C# programming level, but none of your posts describe any SQL development experience. Twice I've mentioned tSQLt. You may want to take a look, it might help. My apologies if it seemed like I was attacking you. Certainly wasn't my intention.
A few pages back Jeff Moden wrote:
And, that's why I don't care for what people are calling "Unit Tests". It doesn't make sense to have two pieces of code to maintain and get both right.
I agree 1,000% with this
You should maybe read the first comment Jeff posted in this thread 😛
Great article, Ed. And, I've found the comment above to be incredibly accurate. What I've personally found at the companies that I've worked at is that unit testing and a peer review process typically saves 8 times (or more as complexity of the code increases) the actual development time. This is particularly true in "utility code" that will be used in many areas regardless of complexity.
I've also found that, once a team has gotten into the habit of unit testing, it usually doesn't increase development time. In fact, we've found that it will, many times, actually save on development time because the processes that we've setup for unit testing have actually streamlined the development process.
August 19, 2019 at 7:28 pm
Most of the effort should go into thinking about what you want to test and why.
Does a test of an insert statement keep on working? If NO then it could be that the underlying table structure has changed and your insert proc or insert C# had been forgotten. In my experience a lot of bugs are ear burningly embarrassing and simply shouldn't have happened but they do and always will. Belief in infallibility is evidence of falibility
August 19, 2019 at 7:51 pm
Steve Collins wrote:chris geswein wrote:Not really. Saying that I don't think you understand, is not an ad hominem attack. I also didn't mean it as an insult, just trying to figure out where you're misunderstanding is coming from so that I can help you understand. Your very first post mentioned your viewpoint from a C# programming level, but none of your posts describe any SQL development experience. Twice I've mentioned tSQLt. You may want to take a look, it might help. My apologies if it seemed like I was attacking you. Certainly wasn't my intention.
A few pages back Jeff Moden wrote:
And, that's why I don't care for what people are calling "Unit Tests". It doesn't make sense to have two pieces of code to maintain and get both right.
I agree 1,000% with this
You should maybe read the first comment Jeff posted in this thread 😛
Great article, Ed. And, I've found the comment above to be incredibly accurate. What I've personally found at the companies that I've worked at is that unit testing and a peer review process typically saves 8 times (or more as complexity of the code increases) the actual development time. This is particularly true in "utility code" that will be used in many areas regardless of complexity.
I've also found that, once a team has gotten into the habit of unit testing, it usually doesn't increase development time. In fact, we've found that it will, many times, actually save on development time because the processes that we've setup for unit testing have actually streamlined the development process.
Why pick the first thing he said? I chose the last thing! He had pretty much the same conversation we're having and already made the distinction between testing to make sure it's correct (and passes review) and a formal framework that adds quite a bit of work. Of course he can speak for himself but nothing in what he wrote suggests to me he follows a unit testing framework in Sql. Or thinks it's a good idea.
Aus dem Paradies, das Cantor uns geschaffen, soll uns niemand vertreiben können
August 19, 2019 at 7:54 pm
Why pick the first thing he said? I chose the last thing! He had pretty much the same conversation we're having and already made the distinction between testing to make sure it's correct (and passes review) and a formal framework that adds quite a bit of work. Of course he can speak for himself but nothing in what he wrote suggests to me he follows a unit testing framework in Sql. Or thinks it's a good idea.
Correct but that's very different than your position which seems to be SQL can't be unit tested at all.
August 19, 2019 at 9:03 pm
Why pick the first thing he said? I chose the last thing! He had pretty much the same conversation we're having and already made the distinction between testing to make sure it's correct (and passes review) and a formal framework that adds quite a bit of work. Of course he can speak for himself but nothing in what he wrote suggests to me he follows a unit testing framework in Sql. Or thinks it's a good idea.
Correct but that's very different than your position which seems to be SQL can't be unit tested at all.
My original post said it was basically fruitless. Not impossible tho I do question the absolute utility. My suspicion is that there is very, very little benefit or none at all. Is documentation the only benefit? Red Brick, Apex, Toad, they all have built documentation tools that are fully auto generating. Where I work we test the API's with curl scripts. We have separate tests for accuracy, resiliency, and performance. If any procs return unexpected results to the API (which is C#) it's logged and I get a report with the name of the proc, the error level, the error code, the line #, etc. Then I fix what's broken. It does happen occasionally 🙂
Aus dem Paradies, das Cantor uns geschaffen, soll uns niemand vertreiben können
August 19, 2019 at 9:15 pm
ZZartin wrote:Why pick the first thing he said? I chose the last thing! He had pretty much the same conversation we're having and already made the distinction between testing to make sure it's correct (and passes review) and a formal framework that adds quite a bit of work. Of course he can speak for himself but nothing in what he wrote suggests to me he follows a unit testing framework in Sql. Or thinks it's a good idea.
Correct but that's very different than your position which seems to be SQL can't be unit tested at all.
My original post said it was basically fruitless. Not impossible tho I do question the absolute utility. My suspicion is that there is very, very little benefit or none at all. Is documentation the only benefit? Red Brick, Apex, Toad, they all have built documentation tools that are fully auto generating. Where I work we test the API's with curl scripts. We have separate tests for accuracy, resiliency, and performance. If any procs return unexpected results to the API (which is C#) it's logged and I get a report with the name of the proc, the error level, the error code, the line #, etc. Then I fix what's broken. It does happen occasionally 🙂
https://tsqlt.org/unit-test-sql-server-code/
There's a couple articles here on the benefits. I wouldn't say it's fruitless, I still think you have some misunderstandings. I find it beneficial, but if you're getting errors from somewhere else, maybe it's less beneficial for you.
August 19, 2019 at 9:22 pm
My original post said it was basically fruitless. Not impossible tho I do question the absolute utility. My suspicion is that there is very, very little benefit or none at all. Is documentation the only benefit? Red Brick, Apex, Toad, they all have built documentation tools that are fully auto generating. Where I work we test the API's with curl scripts. We have separate tests for accuracy, resiliency, and performance. If any procs return unexpected results to the API (which is C#) it's logged and I get a report with the name of the proc, the error level, the error code, the line #, etc. Then I fix what's broken. It does happen occasionally
And the point of unit testing is to fix as many of those issues as possible before they break something else. It sounds like you're avoiding put in a little extra work up front but creating a lot more work and delay for everyone long term. Maybe if you're the sole developer of the full stack that's not a big deal since ultimately it only really impacts you(although I still think unit testing is more efficient than running an entire application just to test a proc or something) but otherwise a single issue can potentially impact a lot more people.
August 20, 2019 at 7:44 am
I can give a really good example of why "well written" unit tests are valuable.... it's not about new code
imagine you have a table of people and there is a constraint on the field called "email" … there is a unit test to check if len(email)>50
someone decides that we can allow delimited emails 'fred@fred.com;simon@simon.com' etc
some idiot removes the constraint or changes the field length, the unit test still will tell us something is not correct
at that point we either change the test or roll back the change.... either way, the unit test warned us
MVDBA
August 20, 2019 at 1:49 pm
My view is that I don't want to test everything I do in the database. Some things I count on Microsoft doing correctly. I also don't want to duplicate effort that application testing covers. What I do want to test, or be sure I test, are the places where I manipulate data in some way that is used in another process, especially a database process. CASE statements, aggregations, even complex joins that pull data from more than lookup tables/fact tables.
This gives me two things. First, I can set up unit tests to cover a number of data cases, which isn't always easy to do in an application unit test. Second, I get documentation. As ZZMartin noted above, I may have rules in my business that have caused me to declare a certain structure. I want to be sure future developers, including me, know this was set up for a reason with this documentation. Testing documentation is more immediate and not easy to ignore, unlike other documentation.
Lastly, this is a flag when someone refactors other code. This lets me know that there is a potential breaking change. So while I don't want to prevent changes to a table/view, I might want a test that guarantees a certain set of columns, essentially an API, because other downstream processes can break. This wouldn't cause issues with new columns, but if someone is refactoring and trying to alter the data model, or do something like a rename, I want a unit test failing that flags this as a potential issue to other systems. We can make the change, but it needs to be coordinated.
Most of this seems simple. In a busy world, with multiple people, and staff turnover, these types of things break all the time. I also find that things like discontinuities or incorrect >/>= choices are exposed quicker when we specifically have a test and show someone that at quantity x we compute y and quantity x+1 we get z. This often finds issues that get lost in casual communication between busy analysts and overworked developers.
Viewing 12 posts - 76 through 86 (of 86 total)
You must be logged in to reply to this topic. Login to reply