Service Virtualization

 View Only

Tuesdays Tips: LISA_PROJ_ROOT and LISA_TC_PATH - how and when to use.

  • 1.  Tuesdays Tips: LISA_PROJ_ROOT and LISA_TC_PATH - how and when to use.

    Broadcom Employee
    Posted May 27, 2015 04:17 PM

    These two variables "seem" like great answers when working with MAR files.  After all, by their definitions:



    The fully qualified path of the project directory. The value is operating system-independent. A forward slash / is used as the separator character on all operating systems, including Windows. The following example is based on a Windows installation:

    C:/Program Files/LISA/examples  


    The fully qualified path of the directory where the test case is located.


    "Fully qualified path" are generally the words we ALL want to hear and read when looking for a variable to write/read files from when authoring test cases.  I was surprised when I went to use these two properties and I got varying results when I was helping a Client with the same concerns.  As I investigated this, I found that this has been an ongoing concern since LISA 6 (and just a little before) when the definition of these two properties changed as the concept of MAR and MARI files matured.  The definitions above are correct, but should be expanded to state "Once a test is staged, LISA_PROJ_ROOT and LISA_TC_PATH are relative to the lads directory when staging a test case. This enables LISA to copy a mar to any machine, and LISA_PROJ_ROOT/LISA_TC_PATH are relative to the location of the MAR on that machine, not to the machine where the test was authored."


    As a result, if you use the LISA_PROJ_ROOT property, the project root will change when staged (i.e. not using ITR) to the tmp folder value (variable between environments in structure and name and configurable in the file), the .mar is unzipped into LADS/"GUID" folder, and then all is removed once complete. This applies to current DevTest GA all the way back through LISA 6.  As a result, in Windows, the path that use to be "C:/LISA/examples" using LISA_PROJ_ROOT in ITR will become "C:/Users/<<LOGIN_ID>>/lisatmp_<<VERSION>>/lads/<<GIUD>>/Examples" when this same test case is staged.


    NOTE:  I would like to stress at this time, if you want all your files that you are creating to be deleted when you are finished with the test case, using LISA_PROJECT_ROOT is the best practice method to use.


    However, if you are expecting these properties to be consistent between ITR and Staging, then you have hit the same tripping place as many people.  In addition, if you are running multiple test cases and they are not in the same MAR file, then the files that each test case wrote are deleted when the test case finishes.  This may be exactly what you want if you are not sharing file contents between test cases.  This may disastrous if you are expecting that file to be hanging around to pass valuable information between test cases.  Imagine wanting to specify a specific file with specific data to drive your test cases and you expect it to be relative to a path that contains either of the two mentioned paths.  It works on your machine when you us ITR, but does not when you Quick Test it or Stage the test.  What is the root cause for the failure?  LISA_PROJ_ROOT and LISA_TC_PATH change values depending on the use case.


    Why is this the way it was designed?  Portability.  MAR files are expanded in the tmp folder pointed to by the DevTest Properties when staged. When a test case is ran in ITR, the paths are the paths used in the immediate Project.


    If you want to reference the same file from multiple tests, please put the file outside of the project in a folder such as C:\ProjectFolder\ so that the file's location is consistent for each run and each user on that system. The same goes for writing files out - reference a location outside of the project such as C:\ProjectFolder\DataOut and put your outbound files there.


    Now, how can you take this further and have that path variable between system environments? You will need to create a property or two or more (windows_projectPath, unix_projectPath, and file_full_path_name for instance) and put them in the config file. In the test case, determine the type of operating system you are on via a property such as {{}} and build the path according.  This is where I ran into another common stumbling block.  How can I concatenate 2 or more properties to make a complete path?  I know my project path, I know my project sub name, and I know my file name.  All three are properties.  How can I concatenate all three into a single file path?  I went to a Output Log Message step and created the following line:




    This allowed me to have an environmentally variable path (windows in this case), a specific Project path, and a variable file name.  This would allow me to use the same construct, say in a sub process, to open files independent of the OS system that I was using.


    If you have any questions, please feel free to ask.