improve: showcase issue where updating the spec with SSA removes the finalizer

[csviri]

No description provided.

[metacosm]

I'm not sure what the purpose of this test should be? More precisely, I'm not sure we should add showcases to the test suite, such examples are probably better be put in the samples, rather as it's not testing anything in our implementation and just adds to the test running time.

[csviri]

I'm not sure what the purpose of this test should be? More precisely, I'm not sure we should add showcases to the test suite, such examples are probably better be put in the samples, rather as it's not testing anything in our implementation and just adds to the test running time.

fair point, yes, it definitely adds to test running time, although these tests are relatively fast. We already have integration tests which are just showing some issue, or some corner cases. My goal was with these to add them to the test suit, so I can reference it from an upcomin blogpost, what will be also published from JOSDK repo.
I would not add it to the examples, IMO we should keep them clear, and mainly as easy to understand as possible for users who are starting to work with the framework.
Alternatively I could add it to a separate repo, which is also a bit problematic to separatelly maintain. Or just don't merge it and mention show code snippets in the blog, but I think it is always good if users can checkout and experiment with it.
Also it is good for us in the future for development purposes, like when reproducing issues to have such tests at hand.

Regarding the runtime of these integration tests is now something horrible, for a full e2e / IT test suit is ok to have a longer running time.

[xstefank]

I agree with @metacosm that we might consider spliting samples (especially if we want to add more of them) into a separate repo. We can set up GH actions to maintain them as if they would be in this repo.

[csviri]

I agree with @metacosm that we might consider splitting samples (especially if we want to add more of them) into a separate repo. We can set up GH actions to maintain them as if they would be in this repo.

The only objection to that, is it would be much harder to maintain an index, since we cannot use the same approach as here:
#2953

Note that we could also have these in a separate package and run them with a separate GitHub action, so it does not add to the time of the standard integration test suite. cc @metacosm what do you think about that?

I generally find having it in a separate repo as an unnecessary maintenance burden, for example, we would have to bump the josdk version on every release in that repo, also to think about that every time we change something. If we run these as a parallel GitHub action, basically, it has no downside, at least not what I can see.

I agree that these tests are a bit different than the current integration tests, but those already serves dual purpose:
test the functionality and shocase the usage. True that these tests just showcases some situation.