Variables from the Application.properties file are not being resolved in the Test Case Docs tab of the Jameleon GUI.
I am finally trying to update jameleon to 3.3-RC1. I broght over the script below and got it to run and pass. But I need the Test Case Docs tab to resolve the variables used in the functionID attribute of the tag, so testers know what they're running. What do I need to fix?
The script:
<jm:testcase xmlns:jm="jelly:jameleon" xmlns:j="jelly:core">
<jm:test-case-summary>
Verify email addresses in xconf files are test email addresses
</jm:test-case-summary>
<jm:test-case-author>Jeff</jm:test-case-author>
<jm:verify-customer-xconf-dir
functionId="Verify customer xconf folder is '${CUST_XCONF_DIR}' in the global ESS.XCONF"
HOST="${HOST_NAME}"
USER_NAME="${USER_NAME}"
PASSWORD="${PASSWORD}"
XML_FIlE="${ESS_SERVER_XCONF_PATH}/ess.xconf"
EXPECTED_XML_VALUE="${CUST_XCONF_DIR}"
/>
<jm:verify-server-customer-xconf-emailAddresses
functionId="Verify the 'To:' Email Addresses in xconfs at ${localCustomerXconfPath} are ${EMAIL_ADDRESSES}"
HOST="${HOST_NAME}"
USER_NAME="${USER_NAME}"
PASSWORD="${PASSWORD}"
SERVER_LOC="${serverCustomerXconfPath}"
xConfFolder="${localCustomerXconfPath}"
EmailAddreses="${EMAIL_ADDRESSES}"
/>
</jm:ju-session>
</jm:testcase>
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Normally, I would create a file called 'ess-utuxas47.properties' and place the variables in there. If you insist on using Applications.properties, then your variables should start with 'ess-utuxas47.'
I see you have both uppercase and normal type variables being defined somewhere. Are both types of variables defined in the properties files?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry for the confusion, I am using a properties file called ess-utuxas47.properties in the /res directory. (I just though a more generic reference in the subject line was a good idea, I guessed wrong.)
The variables resolve fine when the test case script is run, it even passes. They just don't appear correctly in the test case docs tab.
The upper case variables are pulled from the properties file. There are 2 jelly vars defined in the script.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry, I should have caught that in the first place. One of the "new" features is that the variables are no longer resolved. they get resolved when you run the test and show up in the HTML results, but not in the GUI.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It's a design trade-off. That one feature made Jameleon messy and hard to maintain. There is something we might be able to do, but I haven't looked into it for a while now and I could be wrong. There is a testcase tag attribute called 'executeTestCase'. If you set that to false, then it just runs through the tags, generating the documentation, but not executing the meat of the tag. This is also a global variable that can be set in jameleon.conf. In other words, the GUI should be able to get the Configurator, set the executeTestCase to false, run the test and then set it back to what it was before.
Feel free to dig through the code and try to figure it out. Don't please don't forget to write unit and acceptance tests for any code changes. Once you think you have something that works and passes all new tests w/o breaking existing tests, then submit the code and let's see what we can do.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Setting the 'executeTestCase' attribute to false didn't resolve the jelly variables in the Test Case Docs tab.
It looks like a jelly context is only used during testcase tag run, and not for TestCaseDocsExecutor run method. So even after running the testcase, the variables that are resolved during runtime, are not passed back to the test case dos pane. TestCaseDocsExecutor run method uses a whole different strategy, this must be the design change you're talking about. I can see where the old method gummed this up.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, right now we are using a template to generate the docs in the GUI. Maybe we can have a feature that will show them the finished docs by clicking on a button or something. When the button is clicked, the script is executed, but with executeTestCase turned off. This will basically generate the object tree you are looking for that then in turns generates the test case docs.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Variables from the Application.properties file are not being resolved in the Test Case Docs tab of the Jameleon GUI.
I am finally trying to update jameleon to 3.3-RC1. I broght over the script below and got it to run and pass. But I need the Test Case Docs tab to resolve the variables used in the functionID attribute of the tag, so testers know what they're running. What do I need to fix?
The script:
<jm:testcase xmlns:jm="jelly:jameleon" xmlns:j="jelly:core">
<jm:test-case-summary>
Verify email addresses in xconf files are test email addresses
</jm:test-case-summary>
<jm:test-case-author>Jeff</jm:test-case-author>
<jm:ju-session application="ess-utuxas47" beginSession="false" sessionDelay="10">
<j:set var="serverCustomerXconfPath" value="${ESS_SERVER_XCONF_PATH}/${CUST_XCONF_DIR}" />
<j:set var="localCustomerXconfPath" value="${LOCAL_DIR}/conf/${CUST_XCONF_DIR}" />
<jm:verify-customer-xconf-dir
functionId="Verify customer xconf folder is '${CUST_XCONF_DIR}' in the global ESS.XCONF"
HOST="${HOST_NAME}"
USER_NAME="${USER_NAME}"
PASSWORD="${PASSWORD}"
XML_FIlE="${ESS_SERVER_XCONF_PATH}/ess.xconf"
EXPECTED_XML_VALUE="${CUST_XCONF_DIR}"
/>
<jm:verify-server-customer-xconf-emailAddresses
functionId="Verify the 'To:' Email Addresses in xconfs at ${localCustomerXconfPath} are ${EMAIL_ADDRESSES}"
HOST="${HOST_NAME}"
USER_NAME="${USER_NAME}"
PASSWORD="${PASSWORD}"
SERVER_LOC="${serverCustomerXconfPath}"
xConfFolder="${localCustomerXconfPath}"
EmailAddreses="${EMAIL_ADDRESSES}"
/>
</jm:ju-session>
</jm:testcase>
Which version of Jameleon are you using?
Normally, I would create a file called 'ess-utuxas47.properties' and place the variables in there. If you insist on using Applications.properties, then your variables should start with 'ess-utuxas47.'
I see you have both uppercase and normal type variables being defined somewhere. Are both types of variables defined in the properties files?
I'm upgrading from 3.2.2.
Sorry for the confusion, I am using a properties file called ess-utuxas47.properties in the /res directory. (I just though a more generic reference in the subject line was a good idea, I guessed wrong.)
The variables resolve fine when the test case script is run, it even passes. They just don't appear correctly in the test case docs tab.
The upper case variables are pulled from the properties file. There are 2 jelly vars defined in the script.
Sorry, I should have caught that in the first place. One of the "new" features is that the variables are no longer resolved. they get resolved when you run the test and show up in the HTML results, but not in the GUI.
OK, thanks.
Is that a design trade-off? Or is this something that could be added back in? (if someone was willing to help out and put in the time?)
It's a design trade-off. That one feature made Jameleon messy and hard to maintain. There is something we might be able to do, but I haven't looked into it for a while now and I could be wrong. There is a testcase tag attribute called 'executeTestCase'. If you set that to false, then it just runs through the tags, generating the documentation, but not executing the meat of the tag. This is also a global variable that can be set in jameleon.conf. In other words, the GUI should be able to get the Configurator, set the executeTestCase to false, run the test and then set it back to what it was before.
Feel free to dig through the code and try to figure it out. Don't please don't forget to write unit and acceptance tests for any code changes. Once you think you have something that works and passes all new tests w/o breaking existing tests, then submit the code and let's see what we can do.
OK, we'll hava look. Thanks for the info.
Setting the 'executeTestCase' attribute to false didn't resolve the jelly variables in the Test Case Docs tab.
It looks like a jelly context is only used during testcase tag run, and not for TestCaseDocsExecutor run method. So even after running the testcase, the variables that are resolved during runtime, are not passed back to the test case dos pane. TestCaseDocsExecutor run method uses a whole different strategy, this must be the design change you're talking about. I can see where the old method gummed this up.
Hi Jeff,
Yes, right now we are using a template to generate the docs in the GUI. Maybe we can have a feature that will show them the finished docs by clicking on a button or something. When the button is clicked, the script is executed, but with executeTestCase turned off. This will basically generate the object tree you are looking for that then in turns generates the test case docs.