locked
msTest fails if LoadTestPlugin is specified for loadtest RRS feed

  • Question

  • Hi,

    I'm having trouble running a load test from the command line if a load test plugin is specified in the .loadtest file. It runs fine when I kick the test off from Visual Studio.

    mstest /testcontainer:mytest.loadtest /runconfig:local.testrunconfig

    It goes through, loads the configuration files and then starts executing the test. As soon as it starts, it comes back with an 'error in mytest'.

    If I set the LoadTestPluginClass to an empty string, the test runs fine. How is it supposed to find the plug-in? In VS, you have a reference to it in the project, so it can find its location that way. When you kick it off from mstest, the VS project does not come into play. The plug-in and the load test file were all in the same folder. I tried specifying the path to assembly, but that did not work either.

    This is what VS put there when I added the plugin:

    LoadTestPluginClass="MyAssembly..LoadTestPlugin.LoadTestPlugin, MyAssembly.LoadTestPlugin"

    What am I missing?

    Thanks.

    Wednesday, June 28, 2006 8:55 PM

Answers

  • Add the dll that the load test plugin is in to the deployment section of the runconfig file that you are specifying.
    Wednesday, June 28, 2006 9:23 PM
    Moderator

All replies

  • Add the dll that the load test plugin is in to the deployment section of the runconfig file that you are specifying.
    Wednesday, June 28, 2006 9:23 PM
    Moderator
  • Thanks for the tip.

    There seems to be a difference in how referenced DLL are copied between VS Studio and MSTest. If you run a test from within VS, just having a reference to a DLL will result in that DLL being copied over to the test deploy directory as long as the 'CopyLocal' property is set to true. It does not matter if you actually use the referenced DLLs anywhere in your code.

    When running the same test from the command line,  simply having a reference to a DLL will not result in that DLL being deployed. You actually have to declare a variable of a type exposed by the referenced assembly somewhere in your code in order for the DLL to be deployed.

    Your suggestion of including the plug-in in the deploy section of the testrunconfig file works, but it is problamatic if you have several different run configurations that need to be portable between multiple machines and the plug-in DLL is not necessarily located in the same location as the solution that contains the testrunconfig file. You end up hard coding a path in the deploy section of the testrunconfig file which ties it to a particular machine or you require every machine to have an environment variable set up that can be referenced in the deploy section of the config file, provided it respects variables at all. There did not seem to be a way to reference a variable in the UI. It may or may not respect it if you edit the underlying XML file and put it in by hand. I did not try it.

    I ended up adding a dummy class to each unit test assembly that is used in a load test that declares a variable of a type exposed by the plug-in DLL. For us, at least, that seems to involve less maintenance work than making sure the config files are all set up correctly. I do not particularly like this approach either, because the unit test class does not even need a reference to the plug-in otherwise.

    If you can think of a cleaner way push out plug-ins, let me know.

    Thursday, June 29, 2006 8:44 AM
  • I've only tried this with webtest plugins, not loadtest plugins, so the behavior may be completely different, but in my build scripts I:

    1.) Complie

    2.) Copy the plugin's dll to ${mstest.directory}/PrivateAssemblies

    3.) Run the test

    4.) Delete the copied dll from ${mstest.directory}/PrivateAssemblies

    MsBuild always searches that directory, so dropping the plugins there seems to work well.  In my opinion, this is a little cleaner since it only contaminates the build script.

    Hope this helps!

    Wednesday, July 19, 2006 6:55 PM