Writing until tests and using properties from airavata-server.properties

[Lahiru Gunathilake <gl...@gmail.com>]

Hi Devs,

During unit test writing, we need some of the properties to be set and
currently in airavata we have airavata-server.properties in only one place.
 When we retrieve them from ServerSettings.java and ClientSettings.java we
give higher preference to the system property with the same key and then we
read from airavata-server.properties.

So during until test writing we can use this feature and set your required
properties in your test case and use them. If there are properties which
needs to be provided by the person who run the tests (ex: myproxy password,
certificate location) we can read these from maven system property setting
like below.

mvn clean install -Dmyproxy.password=xxx.

I have finished the tests cases for gsissh,job-monitor,orchestrator-core
and gfac-core using the the above mentioned model. With this approach we do
not need to duplicate airavata-server.properties all over the modules.

Meantime we can have a test for our sample
airavata-server/client.properties files to check whether our sample
properties file we ship is syned with the code which reads them.

Regards
Lahiru
-- 
System Analyst Programmer
PTI Lab
Indiana University

Re: Writing until tests and using properties from airavata-server.properties

[Lahiru Gunathilake <gl...@gmail.com>]

If you don't have credentials you just have to run with default profile
which will skip all the test cases which require credentials.

Once I am done implementing until tests I will send an email with
instructions.

Lahiru


On Sat, Apr 12, 2014 at 12:00 AM, Sachith Withana <sw...@gmail.com>wrote:

> Lahiru,
>
> What happens when the unit tests are run without those properties being
> set? ex: myproxy.password is not check?
>
>
> On Fri, Apr 11, 2014 at 3:25 PM, Lahiru Gunathilake <gl...@gmail.com>wrote:
>
>> Hi Devs,
>>
>> During unit test writing, we need some of the properties to be set and
>> currently in airavata we have airavata-server.properties in only one place.
>>  When we retrieve them from ServerSettings.java and ClientSettings.java we
>> give higher preference to the system property with the same key and then we
>> read from airavata-server.properties.
>>
>> So during until test writing we can use this feature and set your
>> required properties in your test case and use them. If there are properties
>> which needs to be provided by the person who run the tests (ex: myproxy
>> password, certificate location) we can read these from maven system
>> property setting like below.
>>
>> mvn clean install -Dmyproxy.password=xxx.
>>
>> I have finished the tests cases for gsissh,job-monitor,orchestrator-core
>> and gfac-core using the the above mentioned model. With this approach we do
>> not need to duplicate airavata-server.properties all over the modules.
>>
>> Meantime we can have a test for our sample
>> airavata-server/client.properties files to check whether our sample
>> properties file we ship is syned with the code which reads them.
>>
>> Regards
>> Lahiru
>> --
>> System Analyst Programmer
>> PTI Lab
>> Indiana University
>>
>
>
>
> --
> Thanks,
> Sachith Withana
>
>


-- 
System Analyst Programmer
PTI Lab
Indiana University

Re: Writing until tests and using properties from airavata-server.properties

[Sachith Withana <sw...@gmail.com>]

Lahiru,

What happens when the unit tests are run without those properties being
set? ex: myproxy.password is not check?


On Fri, Apr 11, 2014 at 3:25 PM, Lahiru Gunathilake <gl...@gmail.com>wrote:

> Hi Devs,
>
> During unit test writing, we need some of the properties to be set and
> currently in airavata we have airavata-server.properties in only one place.
>  When we retrieve them from ServerSettings.java and ClientSettings.java we
> give higher preference to the system property with the same key and then we
> read from airavata-server.properties.
>
> So during until test writing we can use this feature and set your required
> properties in your test case and use them. If there are properties which
> needs to be provided by the person who run the tests (ex: myproxy password,
> certificate location) we can read these from maven system property setting
> like below.
>
> mvn clean install -Dmyproxy.password=xxx.
>
> I have finished the tests cases for gsissh,job-monitor,orchestrator-core
> and gfac-core using the the above mentioned model. With this approach we do
> not need to duplicate airavata-server.properties all over the modules.
>
> Meantime we can have a test for our sample
> airavata-server/client.properties files to check whether our sample
> properties file we ship is syned with the code which reads them.
>
> Regards
> Lahiru
> --
> System Analyst Programmer
> PTI Lab
> Indiana University
>



-- 
Thanks,
Sachith Withana

Re: Writing until tests and using properties from airavata-server.properties

[Saminda Wijeratne <sa...@gmail.com>]

To add to that, the order of priority in increasing order is as follows,


   1. airavata-server.properties
   2. <external settings file> (see below how this option could be useful)
   3. system property


If you do not want to specify the settings in your java code, you may
define the settings in a property file in src/test/resources (say
"foo.properties") and when starting up the tests, update the system
property "external.settings" as follows,

System.setProperty("external.settings", "foo.properties");
(this will do an in memory merge of foo.properties file with the
airavata-server.properties file)

+1 for tests on airavata-server/client.properties. Any idea how we wanna do
this? One way I can think of is to write unit tests to test existence of
required settings in each of the relevant modules.


On Fri, Apr 11, 2014 at 12:25 PM, Lahiru Gunathilake <gl...@gmail.com>wrote:

> Hi Devs,
>
> During unit test writing, we need some of the properties to be set and
> currently in airavata we have airavata-server.properties in only one place.
>  When we retrieve them from ServerSettings.java and ClientSettings.java we
> give higher preference to the system property with the same key and then we
> read from airavata-server.properties.
>
> So during until test writing we can use this feature and set your required
> properties in your test case and use them. If there are properties which
> needs to be provided by the person who run the tests (ex: myproxy password,
> certificate location) we can read these from maven system property setting
> like below.
>
> mvn clean install -Dmyproxy.password=xxx.
>
> I have finished the tests cases for gsissh,job-monitor,orchestrator-core
> and gfac-core using the the above mentioned model. With this approach we do
> not need to duplicate airavata-server.properties all over the modules.
>
> Meantime we can have a test for our sample
> airavata-server/client.properties files to check whether our sample
> properties file we ship is syned with the code which reads them.
>
> Regards
> Lahiru
> --
> System Analyst Programmer
> PTI Lab
> Indiana University
>