MS Test data-driven tests/.CSV file error: Column ‘columnname’ does not belong to table

This is a maddening error, in the best Microsoft tradition of error-text-tells-you-nothing-about-the-real-cause.

You are happily running your unit tests using MS Test, and you write a new unit test that requires a series of data to be thrown at the test. An example could be testing the validation code of a property setter. A perfect scenario for what Microsoft refers to as a Data-Driven Unit Test. Trying to keep things simple, you right-click on your Test project, click Add –> New Item, and choose “Text File” from the dialog, being sure to change the extension from .txt to .csv when naming the file.

You then open the file by double-clicking it, enter some test data, save the file, then reference the file in the attributes of your test. You finish writing your test, run it, and then…boom! You get the above error. You double-check—and triple-check—that, yes, the column name is there at the top of the column in the .CSV file, and, yes, you have spelled it right. Perhaps you yell at Visual Studio that the column name is right there.

Well, I recently went through this annoyance—for the second time in two years. I didn’t recall the solution until I Googled it; it has to do with the .CSV file’s Encoding.

UTF-8, .CSV, and Visual Studio do not mix

That is pretty much the answer, right there. Fix the encoding of the file.

You need to open the file in Visual Studio, do a Save As, go to the bottom-right corner of the Save As dialog, click the black triangle next to the Save button, and click Save with Encoding—here is what it looks like in VS 2010, although it’s in exactly the same place in VS 2008:

saveWithEncoding

and change the Encoding from UTF-8 to something that makes sense for your scenario/location. In my case that would be “Western European (Windows) – Codepage 1252”, as I am in the U.S.

A large “Gotcha”

At this point, you could simply allow VS to save your file with the same name, okaying the question about overwriting the existing file, but you could get into trouble here if you have already added the file to Source Control. Source Control systems like CVS can get confused if you save a file over an existing file when the only difference is the Codepage, as they can when you try to differentiate between files using only a different casing for the filename.

If you have not yet added the file to Source Control—or you don’t use it—then, go ahead and save the “new” file over the old file.

If, however, you have already added the file, you will need to take a different approach, or you may break things like file diff’ing. It’s not worth taking the chance. Each system varies in how it handles file deletes/re-names/moves, so you should consult your system’s documentation, but you will likely wind up saving the “new” file under a different name, deleting the “old” file, then re-naming the “new” file to the (now deleted) “old” file’s name. Or you may find it simpler to just give the “new” file a different name entirely, and change the code in your unit test to match.

Avoiding the whole issue

Having read the above, you may think “there must be a better way!” Well, there is—if your whole team has a recent version of Microsoft Excel, you can simply use an Excel file, making sure to save the file in a version everyone can open. This avoids the whole encoding issue, although setting up the TestMethod attributes that wire up the data file to the test is a bit more complex than for a .CSV file. You can use VS’s tools for this: on MSDN, How to: Configure a Data-Driven Unit Test, see the section “Setting Properties for Data-Driven Unit Tests.”

Hopefully, this will save someone else the annoyance I went through; and, next time it happens to me, in , say, two years or so, and I Google it, this Blog post will come up! There really isn’t a lot of information on this error out there.


Technorati Tags: ,
Advertisements
  1. #1 by malvika gada on September 13, 2015 - 6:56 am

    Thank you for the post. It solved my problem!!!!

  2. #2 by V on January 9, 2014 - 6:05 pm

    Thank you so, so much for posting this! I was beating my head around the internet for at least 30min trying to figure out the culprit to this problem.

  3. #3 by Thilina on July 24, 2013 - 2:26 am

    This post solved my problem, Thanks.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: