added tests for Create and Split Cascade Refactoring

[jainoshika]

Tests are added for RBCreateCascadeRefactoring and RBSplitCascadeRefactoring in Refactoring-Transformations-Tests.

To broaden test coverage, some edge cases are explored with the help of an LLM. These tests were reviewed to ensure they are correct for the refactoring. If any changes do let me know.

Fixes #12533

[Ducasse]

the previous example is not really good.
I would expect

obj foo.
obj bar.
x := obj baz

[jainoshika]

yes, that should be the expected behaviour. but i see the method implementation does not support complete flattening and assigning the last, rather it depends on where the cursor is placed.

[Ducasse]

I have the impression that the from: argument is not that great

[jainoshika]

i changed it to #example currently. if you may share the reasons behind, i will try to think of more.

[Ducasse]

I have the impression that this refactoring is not fully specified.

[jainoshika]

I have the impression that this refactoring is not fully specified.

I agree, shall i go through the implementation first and check out the issues in it?

[jainoshika]

I made changes in the splitCascade which now flattens cascade and returns last in Assignment.

But i am quite confused how the refactoring is supposed to work. the comment says that it divides in 2 parts so then,
will obj a; b; ^ c; d. return obj a;b. and obj c; d
But in case of assignment, we want the method to flatten the whole cascade like

obj a. 
obj b. 
obj c. 
x = obj d.

[balsa-sarenac]

I think it's really good that we got these tests!
What I don't like is how split cascade works right now. For me, it has weird interface. We should discuss what would be a good interface.

I'd like to suggest we create a small UI that by default does best guess split, then you have small check boxes between message calls where you can check them to make those calls be cascade or not, so user ultimately picks what will be split and what isn't.

We can also rely on selection for splitting - example: all cascades in selection will be split, before or after it we preserve cascade. This might be harder since users don't know this and is not intuitive.

[balsa-sarenac]

For me this would pass, I'd split after first message here, better UX too.

I'm not saying we should implement this in this PR.

[balsa-sarenac]

I'd also expect this to do:

obj foo.
obj bar.
obj baz.

But this might only be me.
I'm not saying we should do this in this PR, we should discuss this.

[jainoshika]

I'd like to suggest we create a small UI that by default does best guess split, then you have small check boxes between message calls where you can check them to make those calls be cascade or not, so user ultimately picks what will be split and what isn't.

I really like this idea, it will give the user more options and control.