4

Resolved

Add Property Command

description

Add a new command type that allows getting or setting properties of tasks within the package.

comments

paulkrug17 wrote Feb 12, 2009 at 1:25 AM

Many tasks in a package are simply to compute variables that are only ever visible internal to the package. They have no external effect such as changing files or tables. But these tasks still need to be unit tested. Without the capability of, for example, getting package user variables there doesn't seem to be a way to unit test the entire package.

I would hope that adding this would enable expected values of asserts to be expressions, not just constants as it seems to be now.

Thanks!

johnwelch wrote Feb 18, 2009 at 4:25 PM

There is a method of getting package user variables, the VariableCommand. This new command will allow you to retrieve a property value and compare it to a literal. For example, you can use it to retrieve the value of a ConnectionManager's connectionstring property, and compare that to a literal connection string value.

Making the expected values of asserts dynamic is a more significant change. Can you provide some scenarios on how you would use that?

paulkrug17 wrote Feb 25, 2009 at 3:56 PM

One example would be setting a user variable to the current date. If the expected value could be something like "getdate()" or "Now().Date()". I can always put today's date in as a literal (e.g., "2/25/2009 00:00:00", but when I run the whole test suite tomorrow, that will now fail. Another example is a task that determines the age of log files (for purging files over, say, 30 days old). If I have a task that determines that age, that will be variable over time. A third example might be to independently determine the number of rows that should be determined by a SQL query. That case is less valuable because all that's being tested is that SQL gets called with the right query and returns the result. Plus, I can get around this case with test setup in some cases.

johnwelch wrote Mar 2, 2009 at 10:58 PM

Thanks, that helps. I've create a new issue for this, since it's really outside the scope of this item. Please see http://ssisunit.codeplex.com/WorkItem/View.aspx?WorkItemId=7208 for it.