[rfc][icedtea-web] Fix CacheReproducerTest

[Andrew Azores]

On 08/30/2013 11:32 AM, Omair Majid wrote:
> On 08/30/2013 11:20 AM, Andrew Azores wrote:
>> On that note - Jiri, wouldn't using the value from Defaults not take
>> into account the user changing the cache location using itweb-settings?
>> Perhaps it makes more sense to use DeploymentConfiguration here to
>> ensure that the reproducer test is actually testing using the cache dir
>> that the user expects to use as a cache dir? This way if you've never
>> changed the cache location in itweb-settings then you get the same path
>> as taking it from Defaults would give you, but it does still also
>> respect if you've changed the cache location.
> This is sort of hand-wavy, but it might be a good idea to keep
> reproducers predictable. When the reproducers are run, they should use a
> 'known' configuration and check for exact paths. A mistake in code (a
> typo in one of the configuration defaults, for example) should be
> detected by the reproducers.
>
> Allowing a user's configuration to affect the test would surely make
> things much less predictable - the opposite of what you want in a good
> automated test.
>
> Thanks,
> Omair
The problem is that as the test is now, it relies on the user leaving
the cache location as default. If you use the default location, which it
is set up to expect, then it works. But if you change the cache location
with itweb-settings, then the reproducer tests all fail due to the cache
location not existing. I can: (1) modify the reproducer to create the
default cache location if it doesn't exist and then use it, or (2) have
the reproducer use the DeploymentConfiguration-specified location
whether or not that happens to be default, or (3) allow the reproducer
to fail if you are not using the default cache location.

I don't think it makes sense to choose (3), which is the current state
of the reproducer, so the choice is really between (1) and (2). I see
what you mean about having much more rigidly defined paths in the test
for predictability, ie choosing option (1), but I think it also makes
sense to use the configured cache path settings, ie option (2). If we
take the second option then this test also catches whether or not the
DeploymentConfiguration settings are actually being modified by the
itweb-settings GUI. On the other hand, option (1) will tell you simply
whether the caching mechanism is working correctly, regardless of if
your particular cache configuration (ie cache location) works or not.
Option (2) can emulate option (1) if you just set the cache location to
default in itweb-settings. Speaking of which, perhaps there should be a
way within that GUI to reset the cache location to default?

-- 
Andrew A