Modifications to TestPackage API

[CharliePoole]

Fixes #17

[manfred-brands]

Changes look good

What is the use case to have both AddSettings and ApplySettings?

[CharliePoole]

After the runner initializes, various settings will exist in the tree of packages -- which is generally the top part of the tree of tests, down to the level of assemblies. The packages will have a number of settings, some propagated to all packages, some unique to a particular level. Other settings, where needed, will end up taking on their default values.

If the runner provides a UI to make changes to parts of the tree -- either for a run or to be saved -- then ApplySetting can be used. AddSetting OTOH is most useful upon iniitialization, when we already know that no other settings are present in lower parts of the tree.

Of course, the console runner has no need of this. It initializes, runs and exits. The TestCentric GUIJ does it extensively and I believe the adapter may be able to use it in a few places.

[CharliePoole]

@nunit/engine-team @OsirisTerje

Ran into a problem tagging this as a new release. Please chime in on nunit/nunit-console#1908

[manfred-brands]

AddSetting OTOH is most useful upon iniitialization, when we already know that no other settings are present in lower parts of the tree.

But if there are no existing settings, Add is the same as Apply.

[CharliePoole]

Yes, exactly so. But the calling code would have to descend the tree of packages and decide at each step whether to use Add or Set. ApplySetting abstracts that process. Of course, we could just use ApplySetting all the time but then we might be silently overwriting values that we shouldn't overwrite.

[manfred-brands]

Hence my question why do we need Add if Set adds if necessary.

[CharliePoole]

As I said... we could conceivably do without it, but the exception may be of use in some cases, And I think which one is used at any point provides a statement of intent that makes the code easier to understand. It's a judgement call.