[Findit] Adding central config test class for unit tests

[Findit] Adding central config test class for unit tests

BUG=583144
Committed: https://chromium.googlesource.com/infra/infra/+/471eee4e9d6e46eccfd4ccebc4987b6aeff0bacc

[lijeffrey, 2016-03-29 19:33:01]

Description was changed from

==========
[Findit] Adding cental config test class for unit tests

BUG=
==========

to

==========
[Findit] Adding cental config test class for unit tests

BUG=583144
==========

[lijeffrey, 2016-03-29 19:33:01]

lijeffrey@chromium.org changed reviewers:
+ chanli@chromium.org, stgao@chromium.org

[lijeffrey, 2016-03-29 19:33:17]

Description was changed from

==========
[Findit] Adding cental config test class for unit tests

BUG=583144
==========

to

==========
[Findit] Adding central config test class for unit tests

BUG=583144
==========

[lijeffrey, 2016-03-29 19:33:45]

PTAL

[stgao, 2016-03-30 01:06:31]

I have comments in the first patchset too.

https://codereview.chromium.org/1836293002/diff/1/appengine/findit/model/test...
File appengine/findit/model/test/configured_test_case.py (right):

https://codereview.chromium.org/1836293002/diff/1/appengine/findit/model/test...
appengine/findit/model/test/configured_test_case.py:1: # Copyright 2016 The
Chromium Authors. All rights reserved.
Is there a specific reason we wanted to add this module in model/?
It seems not a ndb model.

https://codereview.chromium.org/1836293002/diff/1/appengine/findit/model/test...
appengine/findit/model/test/configured_test_case.py:93: class
ConfiguredTestCase(testing.AppengineTestCase):
Maybe scope this to Waterfall? Later we might need the same for Crash.

https://codereview.chromium.org/1836293002/diff/1/appengine/findit/model/test...
appengine/findit/model/test/configured_test_case.py:97:
self.mock_current_user(user_email='test@chromium.org', is_admin=True)
If possible, let's not make this default.

https://codereview.chromium.org/1836293002/diff/20001/appengine/findit/handle...
File appengine/findit/handlers/test/build_failure_test.py (right):

https://codereview.chromium.org/1836293002/diff/20001/appengine/findit/handle...
appengine/findit/handlers/test/build_failure_test.py:127:
configured_test_case.MockConfigSettings()
Is it possible to make BuildFailureTest inherit from 
configured_test_case.WaterfallTestCase instead?

This seems more like a hack.

https://codereview.chromium.org/1836293002/diff/20001/appengine/findit/waterf...
File appengine/findit/waterfall/test/build_failure_analysis_test.py (right):

https://codereview.chromium.org/1836293002/diff/20001/appengine/findit/waterf...
appengine/findit/waterfall/test/build_failure_analysis_test.py:1017:
'step_name': 'step1',
This rename makes it unclear that this step is not supported.

Seems better to rename in the config instead.

https://codereview.chromium.org/1836293002/diff/20001/appengine/findit/waterf...
File appengine/findit/waterfall/test/schedule_try_job_pipeline_test.py (right):

https://codereview.chromium.org/1836293002/diff/20001/appengine/findit/waterf...
appengine/findit/waterfall/test/schedule_try_job_pipeline_test.py:14: def
setUp(self):
This could be removed now.

https://codereview.chromium.org/1836293002/diff/20001/appengine/findit/waterf...
File appengine/findit/waterfall/test/try_job_pipeline_test.py (right):

https://codereview.chromium.org/1836293002/diff/20001/appengine/findit/waterf...
appengine/findit/waterfall/test/try_job_pipeline_test.py:21:
super(TryJobPipelineTest, self).setUp()
Could be removed too.

[lijeffrey, 2016-03-30 23:28:34]

https://codereview.chromium.org/1836293002/diff/1/appengine/findit/model/test...
File appengine/findit/model/test/configured_test_case.py (right):

https://codereview.chromium.org/1836293002/diff/1/appengine/findit/model/test...
appengine/findit/model/test/configured_test_case.py:1: # Copyright 2016 The
Chromium Authors. All rights reserved.
On 2016/03/30 01:06:30, stgao wrote:
> Is there a specific reason we wanted to add this module in model/?
> It seems not a ndb model.

Moved to Findit/waterfall/test

https://codereview.chromium.org/1836293002/diff/1/appengine/findit/model/test...
appengine/findit/model/test/configured_test_case.py:93: class
ConfiguredTestCase(testing.AppengineTestCase):
On 2016/03/30 01:06:30, stgao wrote:
> Maybe scope this to Waterfall? Later we might need the same for Crash.

Done.

https://codereview.chromium.org/1836293002/diff/1/appengine/findit/model/test...
appengine/findit/model/test/configured_test_case.py:97:
self.mock_current_user(user_email='test@chromium.org', is_admin=True)
On 2016/03/30 01:06:30, stgao wrote:
> If possible, let's not make this default.

Done.

https://codereview.chromium.org/1836293002/diff/20001/appengine/findit/handle...
File appengine/findit/handlers/test/build_failure_test.py (right):

https://codereview.chromium.org/1836293002/diff/20001/appengine/findit/handle...
appengine/findit/handlers/test/build_failure_test.py:127:
configured_test_case.MockConfigSettings()
On 2016/03/30 01:06:30, stgao wrote:
> Is it possible to make BuildFailureTest inherit from 
> configured_test_case.WaterfallTestCase instead?
> 
> This seems more like a hack.

Done.

https://codereview.chromium.org/1836293002/diff/20001/appengine/findit/waterf...
File appengine/findit/waterfall/test/build_failure_analysis_test.py (right):

https://codereview.chromium.org/1836293002/diff/20001/appengine/findit/waterf...
appengine/findit/waterfall/test/build_failure_analysis_test.py:1017:
'step_name': 'step1',
On 2016/03/30 01:06:30, stgao wrote:
> This rename makes it unclear that this step is not supported.
> 
> Seems better to rename in the config instead.

Done.

https://codereview.chromium.org/1836293002/diff/20001/appengine/findit/waterf...
File appengine/findit/waterfall/test/schedule_try_job_pipeline_test.py (right):

https://codereview.chromium.org/1836293002/diff/20001/appengine/findit/waterf...
appengine/findit/waterfall/test/schedule_try_job_pipeline_test.py:14: def
setUp(self):
On 2016/03/30 01:06:30, stgao wrote:
> This could be removed now.

Done.

https://codereview.chromium.org/1836293002/diff/20001/appengine/findit/waterf...
File appengine/findit/waterfall/test/try_job_pipeline_test.py (right):

https://codereview.chromium.org/1836293002/diff/20001/appengine/findit/waterf...
appengine/findit/waterfall/test/try_job_pipeline_test.py:21:
super(TryJobPipelineTest, self).setUp()
On 2016/03/30 01:06:30, stgao wrote:
> Could be removed too.

Done.

[stgao, 2016-03-31 18:07:13]

https://codereview.chromium.org/1836293002/diff/40001/appengine/findit/handle...
File appengine/findit/handlers/test/build_failure_test.py (right):

https://codereview.chromium.org/1836293002/diff/40001/appengine/findit/handle...
appengine/findit/handlers/test/build_failure_test.py:126:
self.mock_current_user(user_email='anyone@chromium.org', is_admin=False)
Why we need this? By default, no user is mocked.

https://codereview.chromium.org/1836293002/diff/40001/appengine/findit/waterf...
File appengine/findit/waterfall/test/extract_signal_pipeline_test.py (right):

https://codereview.chromium.org/1836293002/diff/40001/appengine/findit/waterf...
appengine/findit/waterfall/test/extract_signal_pipeline_test.py:440:
unsupported_step_name = 'step6'
We'd better to add 'unsupported_' to the step name 'step6'

https://codereview.chromium.org/1836293002/diff/40001/appengine/findit/waterf...
File appengine/findit/waterfall/test/extractors_test.py (right):

https://codereview.chromium.org/1836293002/diff/40001/appengine/findit/waterf...
appengine/findit/waterfall/test/extractors_test.py:15: super(ExtractorsTest,
self).setUp()
Is this really needed?

https://codereview.chromium.org/1836293002/diff/40001/appengine/findit/waterf...
File
appengine/findit/waterfall/test/process_swarming_task_result_pipeline_test.py
(right):

https://codereview.chromium.org/1836293002/diff/40001/appengine/findit/waterf...
appengine/findit/waterfall/test/process_swarming_task_result_pipeline_test.py:216:
config_settings = wf_configured_test_case.DEFAULT_UNIT_TEST_CONFIG_DATA
How about adding a func in wf_configured_test_case to do the config overwrite
the default values with new values like the one here?

https://codereview.chromium.org/1836293002/diff/40001/appengine/findit/waterf...
appengine/findit/waterfall/test/process_swarming_task_result_pipeline_test.py:240:
wf_configured_test_case.MockConfigSettings()
Why this one is needed? In each test run, the setUp will be called which means
that the config will be reset.

https://codereview.chromium.org/1836293002/diff/40001/appengine/findit/waterf...
File appengine/findit/waterfall/test/wf_configured_test_case.py (right):

https://codereview.chromium.org/1836293002/diff/40001/appengine/findit/waterf...
appengine/findit/waterfall/test/wf_configured_test_case.py:101: class
WaterfallConfiguredTestCase(testing.AppengineTestCase):
nit: WaterfallConfiguredTestCase --> WaterfallTestCase.

No need to mention config explicitly, as we might add something else later.

[lijeffrey, 2016-03-31 22:50:21]

https://codereview.chromium.org/1836293002/diff/40001/appengine/findit/handle...
File appengine/findit/handlers/test/build_failure_test.py (right):

https://codereview.chromium.org/1836293002/diff/40001/appengine/findit/handle...
appengine/findit/handlers/test/build_failure_test.py:126:
self.mock_current_user(user_email='anyone@chromium.org', is_admin=False)
On 2016/03/31 18:07:13, stgao wrote:
> Why we need this? By default, no user is mocked.

Done.

https://codereview.chromium.org/1836293002/diff/40001/appengine/findit/waterf...
File appengine/findit/waterfall/test/extract_signal_pipeline_test.py (right):

https://codereview.chromium.org/1836293002/diff/40001/appengine/findit/waterf...
appengine/findit/waterfall/test/extract_signal_pipeline_test.py:440:
unsupported_step_name = 'step6'
On 2016/03/31 18:07:13, stgao wrote:
> We'd better to add 'unsupported_' to the step name 'step6' 

Done.

https://codereview.chromium.org/1836293002/diff/40001/appengine/findit/waterf...
File appengine/findit/waterfall/test/extractors_test.py (right):

https://codereview.chromium.org/1836293002/diff/40001/appengine/findit/waterf...
appengine/findit/waterfall/test/extractors_test.py:15: super(ExtractorsTest,
self).setUp()
On 2016/03/31 18:07:13, stgao wrote:
> Is this really needed?

Done.

https://codereview.chromium.org/1836293002/diff/40001/appengine/findit/waterf...
File
appengine/findit/waterfall/test/process_swarming_task_result_pipeline_test.py
(right):

https://codereview.chromium.org/1836293002/diff/40001/appengine/findit/waterf...
appengine/findit/waterfall/test/process_swarming_task_result_pipeline_test.py:240:
wf_configured_test_case.MockConfigSettings()
On 2016/03/31 18:07:13, stgao wrote:
> Why this one is needed? In each test run, the setUp will be called which means
> that the config will be reset.

Done.

https://codereview.chromium.org/1836293002/diff/40001/appengine/findit/waterf...
File appengine/findit/waterfall/test/wf_configured_test_case.py (right):

https://codereview.chromium.org/1836293002/diff/40001/appengine/findit/waterf...
appengine/findit/waterfall/test/wf_configured_test_case.py:101: class
WaterfallConfiguredTestCase(testing.AppengineTestCase):
On 2016/03/31 18:07:13, stgao wrote:
> nit: WaterfallConfiguredTestCase --> WaterfallTestCase.
> 
> No need to mention config explicitly, as we might add something else later.

Done.

[stgao, 2016-04-01 18:51:46]

https://codereview.chromium.org/1836293002/diff/60001/appengine/findit/waterf...
File appengine/findit/waterfall/test/wf_configured_test_case.py (right):

https://codereview.chromium.org/1836293002/diff/60001/appengine/findit/waterf...
appengine/findit/waterfall/test/wf_configured_test_case.py:101: class
WaterfallTestCase(testing.AppengineTestCase):  # pragma: no cover.
After the class rename, should we rename the file too?

https://codereview.chromium.org/1836293002/diff/60001/appengine/findit/waterf...
appengine/findit/waterfall/test/wf_configured_test_case.py:109: def
UpdateConfigSetting(self, property_name, setting_name, new_value):
What if the test has to update multiple values? Do we expect the test to call
this func multiple times? Is there a way to do this one time?

https://codereview.chromium.org/1836293002/diff/60001/appengine/findit/waterf...
appengine/findit/waterfall/test/wf_configured_test_case.py:124:
DEFAULT_UNIT_TEST_CONFIG_DATA[property_name][setting_name] = new_value
Is there possible be side effect for this change?

https://codereview.chromium.org/1836293002/diff/60001/appengine/findit/waterf...
appengine/findit/waterfall/test/wf_configured_test_case.py:127:
self.mock_current_user()
Is it possible to avoid this mock and unmock?

[lijeffrey, 2016-04-01 23:06:47]

https://codereview.chromium.org/1836293002/diff/60001/appengine/findit/waterf...
File appengine/findit/waterfall/test/wf_configured_test_case.py (right):

https://codereview.chromium.org/1836293002/diff/60001/appengine/findit/waterf...
appengine/findit/waterfall/test/wf_configured_test_case.py:101: class
WaterfallTestCase(testing.AppengineTestCase):  # pragma: no cover.
On 2016/04/01 18:51:46, stgao wrote:
> After the class rename, should we rename the file too?

Done.

https://codereview.chromium.org/1836293002/diff/60001/appengine/findit/waterf...
appengine/findit/waterfall/test/wf_configured_test_case.py:109: def
UpdateConfigSetting(self, property_name, setting_name, new_value):
On 2016/04/01 18:51:46, stgao wrote:
> What if the test has to update multiple values? Do we expect the test to call
> this func multiple times? Is there a way to do this one time?

I made it so it's possible to update the entire 'swarming_settings'
'try_job_settings', 'steps_for_masters_rules', etc. dicts with 1 call

https://codereview.chromium.org/1836293002/diff/60001/appengine/findit/waterf...
appengine/findit/waterfall/test/wf_configured_test_case.py:124:
DEFAULT_UNIT_TEST_CONFIG_DATA[property_name][setting_name] = new_value
On 2016/04/01 18:51:46, stgao wrote:
> Is there possible be side effect for this change?

Done.

https://codereview.chromium.org/1836293002/diff/60001/appengine/findit/waterf...
appengine/findit/waterfall/test/wf_configured_test_case.py:127:
self.mock_current_user()
On 2016/04/01 18:51:46, stgao wrote:
> Is it possible to avoid this mock and unmock?

Done.

[stgao, 2016-04-01 23:35:48]

https://codereview.chromium.org/1836293002/diff/60001/appengine/findit/waterf...
File appengine/findit/waterfall/test/wf_configured_test_case.py (right):

https://codereview.chromium.org/1836293002/diff/60001/appengine/findit/waterf...
appengine/findit/waterfall/test/wf_configured_test_case.py:124:
DEFAULT_UNIT_TEST_CONFIG_DATA[property_name][setting_name] = new_value
On 2016/04/01 23:06:46, lijeffrey wrote:
> On 2016/04/01 18:51:46, stgao wrote:
> > Is there possible be side effect for this change?
> 
> Done.

Seems the bug is not fixed in the new patch.

https://codereview.chromium.org/1836293002/diff/80001/appengine/findit/model/...
File appengine/findit/model/versioned_config.py (right):

https://codereview.chromium.org/1836293002/diff/80001/appengine/findit/model/...
appengine/findit/model/versioned_config.py:35: if not user and not is_admin and
not users.is_current_user_admin():
As we already pass in the user and is_admin, why we still need
users.is_current_user_admin() and users.get_current_user() below?

We'd better keep one code path instead of too.

https://codereview.chromium.org/1836293002/diff/80001/appengine/findit/model/...
appengine/findit/model/versioned_config.py:35: if not user and not is_admin and
not users.is_current_user_admin():
bug: seems we should use 'or' instead of 'and' here.

https://codereview.chromium.org/1836293002/diff/80001/appengine/findit/waterf...
File appengine/findit/waterfall/test/wf_testcase.py (right):

https://codereview.chromium.org/1836293002/diff/80001/appengine/findit/waterf...
appengine/findit/waterfall/test/wf_testcase.py:106:
self.CONFIG_DATA[setting_name] = new_values
There is a bug. We should not modify shared data for multiple tests. This could
cause unexpected flaky tests.

[lijeffrey, 2016-04-04 21:35:05]

https://codereview.chromium.org/1836293002/diff/80001/appengine/findit/model/...
File appengine/findit/model/versioned_config.py (right):

https://codereview.chromium.org/1836293002/diff/80001/appengine/findit/model/...
appengine/findit/model/versioned_config.py:35: if not user and not is_admin and
not users.is_current_user_admin():
On 2016/04/01 23:35:48, stgao wrote:
> As we already pass in the user and is_admin, why we still need
> users.is_current_user_admin() and users.get_current_user() below?
> 
> We'd better keep one code path instead of too.

Done.

https://codereview.chromium.org/1836293002/diff/80001/appengine/findit/waterf...
File appengine/findit/waterfall/test/wf_testcase.py (right):

https://codereview.chromium.org/1836293002/diff/80001/appengine/findit/waterf...
appengine/findit/waterfall/test/wf_testcase.py:106:
self.CONFIG_DATA[setting_name] = new_values
On 2016/04/01 23:35:48, stgao wrote:
> There is a bug. We should not modify shared data for multiple tests. This
could
> cause unexpected flaky tests.

Done.

[stgao, 2016-04-04 22:07:23]

https://codereview.chromium.org/1836293002/diff/100001/appengine/findit/handl...
File appengine/findit/handlers/config.py (right):

https://codereview.chromium.org/1836293002/diff/100001/appengine/findit/handl...
appengine/findit/handlers/config.py:249: users.IsCurrentUserAdmin(),
nit: Inconsistent with API. is_admin is a key-value arg, while user is a
positional arg.

The testing code seems to have different calling style too.

https://codereview.chromium.org/1836293002/diff/100001/appengine/findit/water...
File appengine/findit/waterfall/test/wf_testcase.py (right):

https://codereview.chromium.org/1836293002/diff/100001/appengine/findit/water...
appengine/findit/waterfall/test/wf_testcase.py:100: if config_data:
As discussed in person, don't keep a copy of config data as it is not used after
config update.

Pass in a override_config_data and use it to update the deepcopy of the default
config data.

[lijeffrey, 2016-04-04 23:56:41]

https://codereview.chromium.org/1836293002/diff/100001/appengine/findit/handl...
File appengine/findit/handlers/config.py (right):

https://codereview.chromium.org/1836293002/diff/100001/appengine/findit/handl...
appengine/findit/handlers/config.py:249: users.IsCurrentUserAdmin(),
On 2016/04/04 22:07:23, stgao wrote:
> nit: Inconsistent with API. is_admin is a key-value arg, while user is a
> positional arg.
> 
> The testing code seems to have different calling style too.

Done.

https://codereview.chromium.org/1836293002/diff/100001/appengine/findit/water...
File appengine/findit/waterfall/test/wf_testcase.py (right):

https://codereview.chromium.org/1836293002/diff/100001/appengine/findit/water...
appengine/findit/waterfall/test/wf_testcase.py:100: if config_data:
On 2016/04/04 22:07:23, stgao wrote:
> As discussed in person, don't keep a copy of config data as it is not used
after
> config update.
> 
> Pass in a override_config_data and use it to update the deepcopy of the
default
> config data.

Done.

[stgao, 2016-04-05 00:13:47]

lgtm with a nit.

https://codereview.chromium.org/1836293002/diff/120001/appengine/findit/water...
File appengine/findit/waterfall/test/wf_testcase.py (right):

https://codereview.chromium.org/1836293002/diff/120001/appengine/findit/water...
appengine/findit/waterfall/test/wf_testcase.py:93: override_data=None):
How about just one parameter ``override_config_data``? To be explicit, the code
looks like this:

config_data = copy.deepcopy(DEFAULT_CONFIG_DATA)
config_data.update(override_config_data)

[lijeffrey, 2016-04-05 00:57:19]

https://codereview.chromium.org/1836293002/diff/120001/appengine/findit/water...
File appengine/findit/waterfall/test/wf_testcase.py (right):

https://codereview.chromium.org/1836293002/diff/120001/appengine/findit/water...
appengine/findit/waterfall/test/wf_testcase.py:93: override_data=None):
On 2016/04/05 00:13:47, stgao wrote:
> How about just one parameter ``override_config_data``? To be explicit, the
code
> looks like this:
> 
> config_data = copy.deepcopy(DEFAULT_CONFIG_DATA)
> config_data.update(override_config_data)

It seems if config_data is more than 1 layer deep (which it is for
steps_to_masters_rules, calling update will overwrite values.

For example,

config_data = {'a': {'b' : 1, 'c': 2}}
config_data.update({'a': {'d': 3}})
 
config_data
{'a': {'d': 3}}

and 'b' and 'c' are lost.

It does work however if calling config_data['a'].update({'d': 3})
config_data
{'a': {'c': 2, 'b': 1, 'd': 3}}

So in our case config_data.update({'swarming_settings': 'task_timeout_hours':
-1}) will cause other swarming_settings to be lost

[stgao, 2016-04-05 01:15:29]

lgtm

https://codereview.chromium.org/1836293002/diff/120001/appengine/findit/water...
File appengine/findit/waterfall/test/wf_testcase.py (right):

https://codereview.chromium.org/1836293002/diff/120001/appengine/findit/water...
appengine/findit/waterfall/test/wf_testcase.py:93: override_data=None):
On 2016/04/05 00:57:19, lijeffrey wrote:
> On 2016/04/05 00:13:47, stgao wrote:
> > How about just one parameter ``override_config_data``? To be explicit, the
> code
> > looks like this:
> > 
> > config_data = copy.deepcopy(DEFAULT_CONFIG_DATA)
> > config_data.update(override_config_data)
> 
> It seems if config_data is more than 1 layer deep (which it is for
> steps_to_masters_rules, calling update will overwrite values.
> 
> For example,
> 
> config_data = {'a': {'b' : 1, 'c': 2}}
> config_data.update({'a': {'d': 3}})
>  
> config_data
> {'a': {'d': 3}}
> 
> and 'b' and 'c' are lost.
> 
> It does work however if calling config_data['a'].update({'d': 3})
> config_data
> {'a': {'c': 2, 'b': 1, 'd': 3}}
> 
> So in our case config_data.update({'swarming_settings': 'task_timeout_hours':
> -1}) will cause other swarming_settings to be lost

ok. We could keep the current implemented approach.

If we want later, the alternative is to write a customized update function to do
the recursive update.

[lijeffrey, 2016-04-05 01:17:09]

The CQ bit was checked by lijeffrey@chromium.org

[commit-bot: I haz the power, 2016-04-05 01:17:18]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1836293002/120001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1836293002/120001

[commit-bot: I haz the power, 2016-04-05 01:18:48]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-04-05 01:18:49]

Try jobs failed on following builders:
  Infra Linux Precise 32 Tester on tryserver.infra (JOB_FAILED,
https://build.chromium.org/p/tryserver.infra/builders/Infra%20Linux%20Precise...)
  Infra Linux Trusty 64 Tester on tryserver.infra (JOB_FAILED,
https://build.chromium.org/p/tryserver.infra/builders/Infra%20Linux%20Trusty%...)
  Infra Presubmit on tryserver.infra (JOB_FAILED,
https://build.chromium.org/p/tryserver.infra/builders/Infra%20Presubmit/build...)

[lijeffrey, 2016-04-05 18:35:33]

The CQ bit was checked by lijeffrey@chromium.org

[lijeffrey, 2016-04-05 18:35:34]

The patchset sent to the CQ was uploaded after l-g-t-m from stgao@chromium.org
Link to the patchset: https://codereview.chromium.org/1836293002/#ps140001
(title: "Rebase")

[commit-bot: I haz the power, 2016-04-05 18:35:42]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1836293002/140001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1836293002/140001

[commit-bot: I haz the power, 2016-04-05 18:39:43]

Description was changed from

==========
[Findit] Adding central config test class for unit tests

BUG=583144
==========

to

==========
[Findit] Adding central config test class for unit tests

BUG=583144

Committed:
https://chromium.googlesource.com/infra/infra/+/471eee4e9d6e46eccfd4ccebc4987...
==========

[commit-bot: I haz the power, 2016-04-05 18:39:44]

Committed patchset #8 (id:140001) as
https://chromium.googlesource.com/infra/infra/+/471eee4e9d6e46eccfd4ccebc4987...