Validating external dependencies

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/validating_external_dependencies.htm]

In any project, there are always external dependencies that your components depend on. Perhaps two of the most common are database tables that you can only read from, and someone else's machine that you need to deploy to. I've found some tips for handling each of these cases.

Verifying that your data works for external datatables

Say that there are datatables that you use, but they are maintained by another department. For example, you may need to use an external table as lookup values in your own records, but someone may change the source table after you've already gotten the value from it. Even worse, those tables might not have any referential integrity on them. Although your component may work perfectly with all your unit-test data, it's very possible that their data could be invalid. Given that you don't have the resources to also test every way that their data could be invalid, it would be nice to run a quick diagnostic check.

One solution is to create a stored procedure to do this. You could check that lookup values still exist in the source table or that certain char/varchar fields don't contain invalid characters. A simple such SP with two rules might be:

Begin     if not exists(select myCode from TblCode where myCode is not null)         Print 'Error: TblCode has a null myCode.'     if exists (select * from TblLocation where [description] like '%&%')         Print 'Error: Location can not contain a & ' End

Verifying someone's else environment is set up correctly.

It seems like every developer I meet, including myself, has the problem of writing code that works on our environment, but fails elsewhere. While sometimes it's a legitimate bug in the code, sometimes it's also a error in the other person's environment. For example, the other machine might be missing the correct prerequisite software or have a bad configuration file. I especially see this problem with Unit Tests because all the developers want to always be able to run all the unit tests on their machine. This means that your code will frequently be run on another's machine.

A solution I've found useful is for the team or testing lead to write a small set of diagnostic tests to check that the environment is set up correctly. These diagnostic tests could include:

• Write "Hello World" to the command line to ensure that test engine is installed correctly
• Access external data stores (such as the database or file system) to ensure that the system is configured correctly.

This way I find that if someone says the tests are failing, I can quickly diagnose if they have an easily-fixable environmental problem like bad config files.