Voice of the DBA

Tag: testing

  • Expected Variables–T-SQL Testing

    After I wrote about creating tables that contain the results I expected, I wondered if I could do the same thing with variables. I was thinking that I’d like to better self-document my tests, and I’d like to be able to do this:

    declare @TimeElapsed.Expected int = 25;

    It turns out that I can’t. This gives me a syntax error and forces me to do this:

    declare @TimeElapsed_Expected int = 25;

    I can’t even do this:

    declare @[TimeElapsed.Expected] int

    I’m slightly surprised, but not overly so. More sad that I can’t easily set variables that follow the same format.

  • Setting Expectations–T-SQL Testing

    I don’t know who started this pattern, as I’ve seen it in a few places. It could have been Sebastian Meine or Dennis Lloyd. Maybe it was Dave Green, who did the Pluralsight course on tSQLt. Not sure, but I like it.

    If I’m looking to set up a test against a table called Customers in my database, in the Assemble section of the test, I’ll create this table:

    create table Customers.Expected
( CustomerID int
, CustomerName varchar(200)
...
, Status int
)

    This would match the exact structure of the Customers table, or at least have the structure I’m testing. If I’m only testing a part of the table, I might not use all the fields.

    However this lets me easily determine what this table is. It’s my expected result set.

  • Anatomy of a tSQLt test

    I’ve been doing some work on testing database code, and working with the tSQLt framework. I really like the framework more and more, and want to continue to use it. The whole idea of testing is a bit immature in database code, and perhaps software in general, but at least the software people are trying to move forward. At least in places.

    As I’ve been learning, and presenting on this, I’ve started to adopt and follow the simple pattern espoused by the tSQLt framework. It makes sense, and it provides what I think is a good format for unit test. The structure is:

    • Assemble
    • Act
    • Assert

    It’s simple, and it makes it easy to see how a test works.

    Assemble

    Declare variables and create tables you need. Insert data, initialize values and ensure that you have an expected environment on which to base your tests. I think this is especially important for database code tests.

    Act

    This is the place you call your code, or perform some action. Usually easy to do, but there are some thing that might be tough to set up.

    Assert

    This is where you assert, or declare something to be true. A value is equal to another. A result set looks like another. Something that you declare to be true, which could be some condition, like an error has occurred. If it’s true, the test passes. If not, it doesn’t.

    More to Learn

    There is lots more to learn, and I’m trying to do more. However I also need others to not only try to write tests, but evaluate how well they work and also publish some code. Explain to people what has worked, AND what hasn’t. Having that information out there, for a large variety of cases, will help others better test their code.

  • A T-SQL Code Testing Guide

    Do we need a guide for code like this one? The piece linked is from a programmer at Google who gives some code review items that should be tested for. I’m wondering we we might want to have something similar for T-SQL code?

    I’ve given a few talks on how I to get started with tqslt, which is a great framework for unit testing T-SQL code. As I’ve learned more about it, and experimented, I’ve been amazed by how flexible it is and how it makes it easy to setup and run tests on T-SQL code. However I can only experiment with the way I code and the tests I think of, and I’m sure there are many other ways in which we can better verify that our queries work as expected.

    Testing has changed since I developed software in VB and C++. It seems that much thought has been given to building better unit testing that can not only catch bugs, but also ensure the code performs as we expect it to. There’s also the idea that we can run these tests in an automated fashion. That helps prevent some bug when we first write code, but it more often ensures code continues to work as we re-factor our work and enhance our applications. More and more I think that the constant and continuous regression testing is at least as important as initial testing, if not more so.

    I really hope that we improve our development processes and testing methodologies for SQL code. It seems that it’s an area where we can also increase the speed at we build better database applications, and improve the quality at the same time. If any of you are formalizing the testing of your T-SQL code, we would be interested in publishing your thoughts and results for others to learn from. Please feel free to submit an article.

    Steve Jones

     

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.5MB) podcast or subscribe to the feed at iTunes and LibSyn.