Refactoring tests incorrectly fail for correct refactorings because the expected output in source form is compared to the refactoring output, which is (mostly) in analyzed (desugared) form

Example:


setup [[
module remove-debug-tests

rules
]]

test RemoveDebugSequential refactoring

foo = id; debug
refactor remove-debug to
foo = id

Unexpected output: Module(“remove-debug-tests”,[Rules([SDefT(“foo”{56365},[],[],Id)])]) instead of Module(“remove-
debug-tests”,[Rules([SDefNoArgs(“foo”,Id)])])

Submitted by Maartje on 26 July 2011 at 09:15

On 26 July 2011 at 09:17 Maartje commented:

using the expected output in analyzed form would not be sufficient,
since the refactoring output may contain (newly inserted) elements in ‘sugared’ form.

Possible solution(s): 1. (re)analyze both refactoring output and expected output before comparison, or 2. analyze expected output and use a diff algorithm that takes desugaring into account as done in layout preservation.


On 26 July 2011 at 09:17 Maartje tagged refactoring

On 26 July 2011 at 11:09 Maartje commented:

Best solution seems to be to generate text for refactor output (using layout-sugar preservation algorithm),
and then to parse this text and compare it to the expected output.

Remark: maybe it would be best to also analyse both outputs, to abstract over small differences such as foo(|) = … en foo = …


On 1 August 2011 at 14:07 Maartje commented:

‘best solution’ does not seem to work because selected causes problems for layout/sugar preservation.


test Simple refactoring

module x
rules
bar1 = debug; id
refactor remove-debug-builder to

module x
rules
bar1 = id

input-ast: Module(“x”,[Rules([SDefT(“bar1”{541431},[],[],Seq(CallT(SVar(“debug”{540326}),[],[]),Id))])])

origin-text:
module x
rules
bar1 = debug; id


On 1 August 2011 at 14:24 Lennart Kats commented:

I suppose you’re right. I didn’t realize it before, but origin-text would return the input string with those brackets in it, because the AST is remapped to the displayed tokens after parsing. These [[ and ]] tokens are easy to filter though: their token kind is IToken.TK_ESCAPE_OPERATOR. It would probably make sense if origin-text and related primitives would treat those tokens as whitespace or if possible even as an empty string.


On 3 August 2011 at 08:40 Maartje commented:

asts are now compared with a compare function that takes into account the sugared as well as the desugared form of the terms in the expected output AST.


On 3 August 2011 at 08:40 Maartje closed this issue.

On 9 September 2011 at 09:45 Lennart Kats tagged 1.0

On 28 December 2011 at 13:13 Lennart Kats tagged @maartje

Log in to post comments