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

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

  • 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.)

    If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.

  • 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)

  • 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.

  • 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)

  • Much time has elapsed. Is this series dead?

  • 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)

  • 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

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

  • 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

  • Is this dead subject?

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

  • 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!

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

  • 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.

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

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