AuthDBProperties - bug fix to get resource file

[dazza-codes]

Fix #90

This fix was working in an integration test (using it in the TB-scripts to run conversions).

[ndushay]

I like what you've done, but I have a couple questions.

[ndushay]

would it make more sense to pass "properties" as an argument to initDataSourceProperties(), since we call it in the constructor(s) and we must instantiate properties before calling it?

[dazza-codes]

Not likely; it is initialized by two different methods and those methods are specific to the type of constructor called. Thereafter, it's available to the init method. This is optimal already.

[dazza-codes]

FYI, I went down that road before and ended up where it is now. For example, if it gets passed, we get pseudo-code like this:

initProps( propertyFile ) {
  if propertyFile == null
    properties = loadResourceProperties
  else
    properties = loadPropertiesFile( propertyFile )
  ...
}

So, putting the initializers in the constructors avoids this null check. I hope that helps?

[ndushay]

I meant pass it the Properties object itself -- the result of loadPropertiesFile() or loadResourceProperties()

[dazza-codes]

Oh, yes, that's possible. The next consideration is how easy the class is to test. As it is, those methods are easier to test (or use in tests). I guess that's why it is this way, rather than those loading methods be void methods. At some point while developing tests, it was easier if they return Properties. It's reasonable to request this, but it could entail more work to change tests as well. Not sure we really gain much? Perhaps we can pair on this rather than play github comment tennis?

[dazza-codes]

If I get your point correctly, it seems your requesting changes like the following:

            // lines 84 - 85 are:
           Properties props = new Properties();
           props.load(iStream);
           // they are replaced by using the instance var
           properties.load(iStream);

I'll try that and see what happens.

[dazza-codes]

OK, the new commit might be what your proposing. (Leaving it as a new commit for review purposes only; if it looks OK, it can be squashed later.)

[ndushay]

Am I misunderstanding this? It seems like this line is calling the class method to get data, and then we are matching below (testConstructor, testConstructorWithString) if the data we got using the same method, but called differently (directly rather than with "getDeclaredMethod"), is equal. I would always expect the same method to give the same result, given the same data ...

It looks like the test was that way before this PR ... just thinking it might be better to check the loaded properties against hardcoded known value strings here.

[dazza-codes]

If the data in the properties file changes without changing any hard-coded values in the test, the test breaks. There are various ways to do this, for sure, and this one suffices to get the job done. If using fixed values is required to merge this, we can do that, but it just shifts that data into two places (the resource file and the test, both of which only exist in the tests).

[dazza-codes]

Yet another way to do this is to assertNotNull, but that's less specific (although less fragile and does not depend on checking specific values).

[ndushay]

I'm ok leaving this as is;

It's true there is a maintenance cost incurred that if you change the data being used for tests, you have to change the hardcoded data in the tests ... but in my experience it is still better to test for actual values than test a method's results against ... the same method's results.

[dazza-codes]

If the tests could get direct access to the resource file without using the class... Or if the tests could create the resource file dynamically... but that's not possible, right? Or it's more work. Either way, there are tradeoffs and resource files have already given me a run around, in more ways than one (better explained in person than go on and on about it here).

[dazza-codes]

The latest commit gets the resource file "directly" in the tests.

[ndushay]

👍

[coveralls]

Coverage decreased (-0.8%) to 45.307% when pulling 866f12e on authdb-prop-file-fix into 5d7fc33 on master.