Introduction to SQL Server Reporting Services – Next Tuesday, August 25
Here’s your chance to sign up for the next virtual class, "Introduction to SQL Server Reporting Services". This "Made Simple" course, taught by Sherri McDonald, a Business intelligence expert from Pragmatic Works, is a great investment for your personal development. If you’re ready to up your game, come on in and join us next Tuesday.
How to Unit Test
Today is Friday…a good day to roll up the topic of unit testing with a simple high level overview of how to Unit Test. Sadly space doesn’t allow for demonstrations of actual unit test code. My intention is to provide direction for your further research on the topic.
You can write unit tests for just about any software language. Some languages are easier to unit test than others due to industry interest or the nature of the language itself. Languages that lend themselves to smaller modules and/or methods are easier to test than others.
Scripting languages may be harder to unit test. SQL, you choose a dialect, is a good example of a more difficult language to test. I have built a practice around unit testing SQL because of the value of unit testing. However, SQL, even using functions or stored procedures, is more difficult to test when dealing with sets of data.
I will often place a section of unit tests inside the creation of a SQL code object exercising the key capabilities of that code. In stored procedures, triggers, or SQL functions, this is an effective way to both write the code, and to validate it fulfills the requirements.
Other languages that fully embrace Unit Testing have huge communities with a deep set of tools built around the practice. There are mature open systems products such as jUnit for Java or nUnit for Dot Net that a developer may simply reference in their code, allowing integration into the development IDE for test development and running directly in the code itself.
jUnit integrates nicely into Software Development IDEs such as Eclipse very nicely. nUnit integrates with Visual Studio through third party Add In tools. nUnit may also be used with Dot Net development tools such as Sharp Develop.
These are my favorite tools because of the capabilities built into them. I don’t have to jump back and forth from one set of software to another in order to create or exercise tests on my code as it is being written. It is highly efficient. I have even developed a wrapper around nUnit allowing me to build unit tests for SQL code as well.
Lest you think I have forgotten the Team edition of Visual Studio from Microsoft and the test capabilities they have included, it has been my experience that their testing capabilities are not anywhere near those of Open Systems tools, require a lot more code, don’t save any money, and the integration is a non-issue since unit tests are already exposed in the Visual Studio IDE through add in tools. This blog from Roy Osherove, and the comments that follow bare this position out.
One technique I learned from colleagues is to add additional stand alone projects in Dot Net Solutions dedicated to tests. Because the tests exercise the code when included in the solutions, Debug builds may exercise the tests. However, because the tests are isolated to specific projects not required for the software to function, a release build is easy to create excluding all unit test code, reducing the size of your final release with little additional effort.
Writing tests don’t do you any good if you don’t verify that they work. I worked in a company where the build was considered BROKEN if a single unit test failed. We even had lights showing the state of the current build; red for broken, green for success. Whenever you would check code into version control, an automated procedure would begin, getting the latest code, building the software, and exercising all of the unit tests from the DEBUG build. Results of test failures were encapsulated into Email and sent to responsible parties. And the lights were turned off or on to reflect the state of the build.
If you didn’t want to be the person who “broke the build” it was pretty easy. All you had to do was run the tests in the projects you had touched prior to checking in. This process takes very little time; much less time than breaking the build and blocking the work of other developers while you fix issues you caused.
Once you begin to understand techniques for unit testing you can begin to create unit tests for just about anything. I have even created unit tests for batch files used to perform database maintenance tasks that become brittle.
That’s a very high level summary of how to Unit Test with no real examples. I suggest you take time to search for jUnit or nUnit on the web if you have not done unit testing before. For those of you with other programming languages without this kind of support, it may provide you with insight as to how you can integrate the concepts.
There are many of us still programming in RPG, Cobol, PL1, etc. that benefit from the practice of unit testing. Perhaps you have techniques you can share in those environments. Do you have tools you have found useful for automating your Unit Testing? Share your comments with us by sending an email to btaylor@sswug.org.
Cheers,
Ben
SelecTViews
With Stephen Wynkoop
Rob Schafer from RevGen Partners talks with Stephen about the ever-growing cloud computing field and how Windows Azure fits into the mix.
[Watch the Show]
$$SWYNK$$
Featured Article(s)
Tools to Facilitate Efficient Data Management (Part 4)
Today’s data management tools provide intelligent automation to reduce the problems inherent in the tedious day-to-day tasks of database administration.