Add TypeChangingDecorator to the unifiedBackendTest

[phako]

Since the TypeChangingDecorator is a prominent use-case the unifiedBackendTest should also test decorated accessors and not just the plain decorators.

This ensures compliance of the decorator behaving according to specification

[mhier]

No, the unified backend test should not do such things. It is supposed to test point by point that the backend/accessor is complying to the spec. It should not mix in high-level tests, otherwise it is very hard (-> basically impossible) to understand the coverage of the test cases (which makes both debugging implementations as well as updating the test after changing the spec very hard and error prone). Also the gain is close to zero, since the spec is written in a way that the accessors work with decorators if they comply to the spec. The test would merely test whether the spec is correct, but it would do this only very sporadic (only very small parts of the spec are covered) but with huge redundancy (each part is tested many times with slightly varying conditions, but without controlling the way how the conditions are changed).

What we do need is a test of the TypeChangingDecorator using the unified backend test (if it doesn't already exist). This can be achieved using a modified exception dummy backend which always hands out decorated accessors.

[killenb]

What we do need is a test of the TypeChangingDecorator using the unified backend test (if it doesn't already exist). This can be achieved using a modified exception dummy backend which always hands out decorated accessors.

That's how I understood it. But you are right, that's not what the ticket says. Could you please either adapt the ticket or create a new one? We should have this test.

[phako]

Yeah, initially I meant the "testUnified" test in CSA, not the UnifiedBackendTest itself and I am currently implementing what you described

[phako]

I had to re-add the labels to make it disappear from the board