Stairway to SQL Server Automated Database Testing Level 1: Why You Need TDD

Question

Stairway to SQL Server Automated Database Testing Level 1: Why You Need TDD

Sebastian Meine

Mr or Mrs. 500

Points: 593
More actions
December 15, 2014 at 3:11 am

#292894

Comments posted to this topic are about the item Stairway to SQL Server Automated Database Testing Level 1: Why You Need TDD

Viewing 15 posts - 1 through 15 (of 20 total)

You must be logged in to reply to this topic. Login to reply

Phil Parkin SSC Guru Points: 246985 More actions · Answer 1

An interesting introduction, thanks Sebastian. I shall look forward to the next items in the series.

Writing tests is clearly an initial overhead, which one expects to be worth the investment in terms of future system stability. I will be interested to see whether you advocate writing test(s) for every single proc in a database, or whether you draw the line somewhere.

I will also be interested in any discussion of testing ETL processes which includes the running of SSIS packages, perhaps using this sort of thing:

exec SSISDB.catalog.start_execution @ExecutionId

(after 'creating the execution' & setting it to run synchronously.)

The absence of evidence is not evidence of absence.
Martin Rees

You can lead a horse to water, but a pencil must be lead.
Stan Laurel

Jeff Moden SSC Guru Points: 1004406 More actions · Answer 2

Great article on what can go wrong and how to make it right, Sebastian. What you've described is a classic failure that could certainly have been prevented by the very methods you good folks took to save the project. Continuing in that vein...

I don't understand all the hulabalu behind "Test Driven Development". It's a concept as old as the hills and has been the key to most successful projects. By "successful", I mean projects that not only hit their target date, but also don't require months or years of rework afterwards because of missed requirements or errors.

Wikipedia has a definition (http://en.wikipedia.org/wiki/Test-driven_development) for TDD as follows:

Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards. Kent Beck, who is credited with having developed or 'rediscovered'[1] the technique, stated in 2003 that TDD encourages simple designs and inspires confidence.

Ok. Let's back the testing horse up a bit. What happens before that? The answer SHOULD be that someone has a defined a task in a design document along with what should happen if everything goes right and what should happen if things go wrong. Those are called "use cases". Without that information, the Developer is just doing his own thing and you have the mouse guarding the cheese along with the huge possibility that the Developer cooked up the wrong kind of cheese.

And, "rediscovered" is absolutely correct. Like I said, TDD is nothing new. It's how successful projects have been done even before computers were invented. Remember such things as "process charts", "functional flow charts", and "fault location diagrams"? They all had tests (decision blocks) for the "happy path" and the "oops, something went wrong" paths. I find it ironic that computers make all of that much easier but, because it's so easy to write code on computer, computers seem to have killed that design process. Computers have made it a whole lot easier to design a bit of functionality and the tests that go with it, add some more functionality and the new tests that go with it, apply, lather, rinse, repeat in a very agile (possible multiple incremental releases) manner but few actually do that anymore.

I also think it incredibly ironic that many of the articles that explain TDD use flowcharts to explain the process when that's actually what is needed as part of the description of tasks to be given to the developer along with the written description and the happy and sad use cases. When was the last time you've seen a flow chart as a Developer?

Stating the obvious, once the Developer has completed given bit of functionality (doesn't have to be the whole shebang... could just be a module) and to overcome the "mouse guarding the cheese" problem, someone or something else needs to do a test following the same description and test cases that the Developer did. Of course, these tests can be written ahead of time but there has to be the understanding that they might have to change because requirements and test cases frequently don't cover things that are discovered during the Development of the solution.

I continue to be amazed at supposed "new" discoveries for writing code that actually aren't new at all. They all boil down to the basics. Someone has to define what the overall goal is, correctly define the pieces (including the happy and sad paths) and the order of release, and then someone has to make it work, make it fast, make it pretty and it ain't done 'til it's pretty and has passed in-development unit testing, integration testing, and UAT. All of that should apply to waterfall and agile development methods.

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

Conrad Muller SSC Veteran Points: 294 More actions · Answer 3

This was management failure from end to end. First they screwed everything up in an ill advise attempt to save money, then they dumped the responsibility for their mistakes on the developers.

I'm glad you guys were able to save the project, and I do use TDD for complex SQL, but the people who really needed to learn a lesson were not techs.

Jeff Moden SSC Guru Points: 1004406 More actions · Answer 4

Conrad Muller (12/31/2014)
This was management failure from end to end. First they screwed everything up in an ill advise attempt to save money, then they dumped the responsibility for their mistakes on the developers.
I'm glad you guys were able to save the project, and I do use TDD for complex SQL, but the people who really needed to learn a lesson were not techs.

+1000

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

Duncan A. McRae SSC Veteran Points: 240 More actions · Answer 5

Duncan A. McRae

SSC Veteran

Points: 240

February 29, 2016 at 12:41 pm

#1861927

Much time has elapsed. Is this series dead?

Jeff Moden SSC Guru Points: 1004406 More actions · Answer 6

Duncan A. McRae - Monday, February 29, 2016 12:41 PM
Much time has elapsed. Is this series dead?

Must've been outsourced. 😉

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

jbbconsulting SSC Journeyman Points: 90 More actions · Answer 7

Why highlight a 3 year old article that is supposed to be part of a series that appears to have never gotten past the first article?

Semper Fi,
Jim Briggs

Lynn Pettis SSC Guru Points: 442467 More actions · Answer 8

Perhaps to encourage the original author to continue the series or find someone else that may be willing to do so.

jbbconsulting SSC Journeyman Points: 90 More actions · Answer 9

I hope that's the case, after reading the article I was excited about this stairway then crushed when I realized it was a non-starter.

Semper Fi,
Jim Briggs

eliassal Default port Points: 1467 More actions · Answer 10

eliassal

Default port

Points: 1467

January 28, 2019 at 11:11 am

#2020313

Is this dead subject?

Steve Jones - SSC Editor SSC Guru Points: 736478 More actions · Answer 11

Steve Jones - SSC Editor

SSC Guru

Points: 736478

January 29, 2019 at 9:22 am

#2020437

Hmmm, I hadn't noticed. I'll check.

Duncan A. McRae SSC Veteran Points: 240 More actions · Answer 12

Steve Jones - SSC Editor - Tuesday, January 29, 2019 9:22 AM
Hmmm, I hadn't noticed. I'll check.

Maybe we commenters could collaborate to write one!

Steve Jones - SSC Editor SSC Guru Points: 736478 More actions · Answer 13

If anyone wanted to tackle another side of this, that would be great.

fregatepllada SSCommitted Points: 1702 More actions · Answer 14

I am just wondering how I managed to do this in Microsoft Access without offshore team by myself without TDD and just for 6 month 🙂 A a developers we tested ETL process more thoroughly. More than this - my ETL code was distributed to 10+ sites where it was ran locally without any problems.