Cheap Shot Your Application’s Import Feature

Yes, it’s one little menu command or maybe button on a toolbar, but the Import… command exposes the soft underbelly of your application.

Dr. CreepyYou know how your developers always shirk adding validation logic to any administrative tools because only administrators will use it, and administrators never try bonehead things? Well, the import feature offers access to the actual data that users normally have to use one or more screens on your application to enter. One or more screens to which developers have possibly added data validation after much prompting and shaming from the QA staff.

But short of actually corrupting the data in the database directly (which is fun, and I’d recommend trying it for its own sake), the import feature offers a means to enter crap into the database (or try to, anyway) that nature did not intend for that database.

Understanding the File

Now, to properly cheap shot your application through the import wizard, you have to know something about what it’s trying to import. For the most part, this piece will talk about flat files that might get sucked into your database, but import commands sometimes work with the contents of other databases or pieces of hardware. Some of the following dirty tricks can apply in spirit, but not in the direct form.

The import wizard will expect the file to come in some sort of standard format. Easy examples are comma-separated value files (CSVs), tab-separated files, and Microsoft Excel spreadsheets (.xls). Other, more specific file formats include fixed-width files, files delimited by things other than commas or tabs (such as the pipe character), XML files, or industry-specific files (such as MOL and SDF files for our chemistry friends or MARC records for our attractive librarian friends).

I say that the spreadsheet-like files are the easiest to work with because you can open them up and look at them to understand what’s going on. It’s particularly easy if you’ve got header rows on the columns; then it’s just a matter of altering the data within to test your import wizard completely. The other forms require a deeper understanding of the file format/schema/standard which you can probably find on the Internet.

To test out the import functionality of the application, you’re going to want to not only make sure that a properly formatted file will import correctly and its data will appear, magically, whenever you try to look at it. Oh, no, you have to make sure that corrupt or improper data in the file fails gracefully. Given the inherent laziness of developers, it will probably fail spectacularly and amusingly.

Punch The Data In The Kidney

Let’s say, for example, we have a data file that should contain first name, last name, e-mail address, and zip code. A properly formatted comma-separatedfile would look something like this:


You run the import wizard, and it just might work.

To break the application, take each element that the application can import (the column in a simple file, the elements in an XML file, and whatnot) and add invalid data to it. For example, if the column is supposed to contain a zip code, you’ll want to enter an alphabetical string (ABCD), a number with a decimal point (12.34), a number with fewer than 5 digits (1234) and a number with more than 5 digits). For the first and last name, enter a string that exceeds the length limit allowed by the database (you should find yourself limited to this on data entry screens). For the e-mail address, enter e-mail addresses that are incomplete, that exceed the length limit, and that use characters not found in e-mail addresses. Ergo, your file will start having lots of lines in it:


You want each error condition on its own line to make sure that you try a record that should succeed except for that problem with the individial datum you’re trying to test.

Hey, I wonder what the application does with white space in the record?

doug ,white,,19891
doug,white ,,19891
doug, white,,19891
doug,white, ,19891
doug,white,, 19891

Hey, what if those are required fields for a record? Shouldn’t we test to make sure you can’t load empty data? Why, yes, we should:


You know, perhaps each record should be unique. In which case, this should be disallowed by the application during import:


You should also check uniqueness by trying to import a row of data that you’ve entered by hand to make sure that the application is not only checking the file for duplicates, but that it is also comparing the file to the existing records in the database. Would that be too much to ask? Well, for your developers who need to step away from their desks from time to time for a quick brainstorming session around the refrigerator with the Mountain Dew Code Red, yes, it is.

Basically, that’s what you do with the data elements of the files themselves. Whether they’re encapsulated in XML elements, columns in a spreadsheet, or 040 $a , you can easily embarrass those rockstars with the big paychecks by putting the wrong kind of information in your import file.

Kick the File in the Knee

But let’s talk about the file itself.

You can also show up the developers by marring the files. If the file has a proprietary format or header information, corrupt it. I don’t mean offer to loan it money to buy it a house which you’ll then buy from the file after a year at 10x what the file is “paying” for it now; I mean replace the elements of the header with junk data. For example, a MOL file depends very clearly on having the data begin on the fourth line:

-ISIS- 02120300062D
17 18 0 0 0 0 0 0 0 0999 V2000

What happens if add an extra line at the top of the MOL file so that the information is out of place?

-ISIS- 02120300062D
17 18 0 0 0 0 0 0 0 0999 V2000


Working with XML files? Create data files that don’t adhere to the schema but use the same element names. Nest things too far. Blast it all to heck!

Now, don’t forget the files themselves. Why, what happens if you have a file with the right extension and it has 0 rows of data in it? Empty files can bomb out applications because administrators, the developers know in their heart of hearts, would never choose to import an empty file

What happens if your file has 1,000,000 rows of data? HAVOC! Let your conscience, and your operating system/PC be your only limitation.

What happens if your file uses DOS line breaks instead of UNIX line breaks, or vice versa? HAVOC!

So there you have it, the basics of testing an importer on an application. It’s almost as much work as testing the GUI itself, which is appropriate since it’s offering a quick and dangerous way to do the same thing the pretty little windows and dialog boxes are. Also, it’s probably doing it without a net, since it’s one little feature hidden behind a single menu command or button. But it gives your users an easy way to junk up their databases without a warning from the application for which they paid so much money.

Also, it will help to get your personal defect count up and lead to fear and loathing amongst the C# dressed men. That, my friends, is worth the time and effort in itself.

Comments are closed.

wordpress visitors