There are properties that can be modified in the environment file of the server that change the way the application functions. QA needs to have UI testing coverage on these areas. However, a problem with this is that once the unit test player starts up and begins executing all UI/unit tests, changes to the environment/properties file will not take effect. Therefore, we need to write our tests in such a way that override what is set in the environment file.

A few examples of flags that affect what we can test in the UI:

To modify flags in a .utest, choose from the following methods:

• Parameterize the seeding to change the way the metadata is loaded
• Modify config properties
  
• Change metadata component initializers

Each one will be discussed in the following information.

Parameterized seeding

• Used for environment file settings that change the way the metadata is loaded (design-time configurable attributes)
• Use this method if an environment file flag requires a database reseed for changes to take effect

The way this method is used is as follows

1. Open the .utest file
2. Navigate to the Overview tab
3. Using the NexJ Studio properties view, Find the properties of the Common (UnitTest) item

4. In the Value area, add the following '((flagName . value)). An example is as follows: 

   '((hierarchySecurityEnabled . #t))

5. By saving this, the following is added to the Source tab
   <UnitTest properties="'((hierarchySecurityEnabled . #t))" variables=... >

Using this method, the environment file flag is overridden. Keep in mind, that because changing this flag requires a database recreate to see the changes, the database will recreate when this test is run.

Modifying config properties

This method is mainly used for run-time (not design-time) configurable metadata changes that affect the server at start-up, but are not *.comp properties like audit.

Using this method simply requires adding an additional line to the .utest Initializer in the form of (hashtable-set! sys:config-properties flagName value)

For example, to enable currency conversion in the environment file, we would use

(hashtable-set! sys:config-properties 'currencyConversionEnabled #t)

Changing metadata component initializers

• Used for environment file settings that change the application by accessing *.comp properties
• Used mainly for Audit settings (read/update)

The way these are used is as follows

1. Declare two additional global variables in the overview tab: 
   1. one for the *.comp property
   2. and one for its value. 
      
      i.e. componentProperty and componentPropertyInitialValue
      
      

2. In the Initializer, set the componentProperty variable to the corresponding *.comp property found by the invocation context: An example for read audit is shown below:

   (set! componentProperty ((((invocation-context)'metadata)'getComponent "System.Auditor")'findPropertyInitializer "readAuditLevel"))
   
   
   ; Return Value
   ; #<PrimitivePropertyInitializer readAuditLevel>

3. In the Initializer, set the componentPropertyInitialValue to its initial value (i.e. the value defined in the environment file). This should be done with the invocation context, as we can't always be certain the environment file will not change. To continue with the previous example, we have 

   (set! componentPropertyInitialValue (componentProperty'value))
   
   
   ; Return Value
   ; "none"

4.  Update the componentProperty to its required value. 

   (componentProperty'value "values")
   
   
   ; Return Value
   ; ()

   Note now that if we were to optionally re-run  (componentProperty'value) we would notice that our return value would now change to "values".

5. Run the unit test.

6. In the Finalizer, you must reset the defaults. To do so, simply add the following to the Finalizer 

   (componentProperty'value componentPropertyInitialValue )