Tag Archives: TDD

Developer Smackdown Podcast #51, TDD with Keith Burnell

In this episode, we talk to Keith Burnell, a Software Engineer with Skyline Technologies in Green Bay, Wisconsin about a topic near and dear to all three of us: Test Driven Development.

DeveloperSmackdown white

Play Now


Show Notes

We discuss Inversion of Control (IOC), Dependency Injection, behavior, mocks/stubs/fakes, what unit testing really means and why we create them religiously on each project we work on.

Resources

 

Show Sponsors

ThatConference is a brand new conference coming to the Kalahari Resort in the Wisconsin Dells on August 13th, 14th, 15th of 2012. This is a conference is founded by Developers who want to create the conference they’ve always want to go to and for a price that’s easy to justify to your boss. First and foremost this is a developer’s conference. 3 days of any technology and nothing but code. You can find more at ThatConference.com.

MSTest Aggravation and a Solution (For Me Anyway)

I’ve created data driven tests many times in Visual Studio and I’ve used Excel spreadsheets, comma separated value (CSV) files and XML.  I’ve even written a blog post or two on the subject.  No matter how many times I do it though, it seems that I always get stuck at the beginning because the data files don’t get deployed. WTF? You’d think I would remember how to do it.  Apparently, that’s not the case cuz tonight I ran into the same fricken, aggravating error message and just stared at it like I’d never seen it before.

Here’s the error message:

“The unit test adapter failed to connect to the data source or to read the data. For more information on troubleshooting this error, see "Troubleshooting Data-Driven Unit Tests" (http://go.microsoft.com/fwlink/?LinkId=62412) in the MSDN Library.”  BTW, this was in VS 2010.

Best part is that if you go to that link, it’s not “Troubleshooting Data-Driven Unit Tests”.  It’s titled "Working with Unit Tests” and it’s under VS 2005.  No troubleshooting tips to be found there.  Nothing that helped anyway.

So, I stared at my code and thought, why can’t MSTest find the stupid file and deploy it?!!! It’s not like it’s hidden.  It’s sitting right there in a folder next to the test.

   1:  [DataSource("Microsoft.VisualStudio.TestTools.DataSource.XML", "|DataDirectory|\\WidthTestData.xml", 
   2:              "Row", DataAccessMethod.Sequential)]
   3:          [DeploymentItem("MyProjTest\\TestData\\WidthTestData.xml")]
   4:          [TestMethod]
   5:          public void WhenObjectCreatedShouldValidateWidthValues()
   6:          {
   7:             ...
   8:          }

 

I did searches on the error and came across many frustrated forum messages trying to find out where the RelativePathRoot is because the DeploymentItem attribute file location is supposed to start from “RelativePathRoot” and go from there.  With that problem in mind, I pointed the DeploymentItem path to many, many variations. Project folder\subfolder\file, ..\subfolder\file, ..\..\subfolder\file, etc. None worked.  I even hardcoded the path and that didn’t work.  Hmmm, a clue.

RelativePathRoot wasn’t the problem.  (BTW, if you were wondering, RelativePathRoot is just the folder of the solution that contains your test project.  Maybe that will be useful to someone.)

I decided to use the Test Settings / Deployment option (double click on “Local.testsettings” in Solution Items and you will get the Test Settings dialog) to force deploy the file rather than rely on the DeploymentItem attribute.  When I clicked on the “Deployment” option I saw it immediately (again).  I forgot to check to see if the “Enable deployment” option was checked.  There’s 45 minutes of aggravation I’ll never get back.

image

Once I clicked that option, my data driven tests started working and all was good – for the moment anyway.  So, keep that in mind when you run into that cryptic error message when you’re creating data driven tests. 

One other thing, setting the file to “Copy always” or “Copy if newer” is NOT the answer.  Don’t do it.

And now, back to my regularly scheduled testing…